Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Expose stable cron jobId in plugin hook context [3 pull requests, 3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71826•Fetched 2026-04-26 05:07:47
View on GitHub
Comments
3
Participants
2
Timeline
7
Reactions
0
Author
scottgl9scottgl9
Participants
scottgl9scottgl9steipetesteipete
Timeline (top)
commented ×3cross-referenced ×3closed ×1

before_agent_reply plugin hooks for cron-triggered agent runs receive runId, but not the stable cron jobId.

For cron workflows, runId is the execution id (for example cron:<jobId>:<startedAt> or a manual execution id), not the persistent cron job identifier. That makes it hard for plugins to match a specific cron job reliably.

Root Cause

Plugins may want to apply logic to one cron job but not another, even when they share the same agent. Matching on agentId is only a coarse fallback.

A stable jobId in hook context would let plugins:

  • target a specific cron job precisely
  • avoid parsing opaque execution ids
  • distinguish multiple cron jobs that use the same agent

Fix Action

Fixed

PR fix notes

PR #71836: feat(plugins): expose stable cron jobId in plugin hook context (#71826)

Description (problem / solution / changelog)

Closes #71826.

Why

Plugins inspecting `before_agent_reply` (and other agent-hook events) on cron-triggered runs receive `runId` (per-execution, e.g. `cron:<jobId>:<startedAt>`) but not the persistent cron `jobId`. That makes per-job logic — "apply rule X to my morning-investor-brief cron only" — rely on parsing opaque execution ids or coarse `agentId` matching.

What

Add an optional `jobId?: string` to `PluginHookAgentContext` and populate it from cron's `params.job.id` through both agent run paths.

changefile
Add `jobId?: string` to `PluginHookAgentContext``src/plugins/hook-types.ts`
Add `jobId?: string` to `RunCliAgentParams``src/agents/cli-runner/types.ts`
Add `jobId?: string` to `RunEmbeddedPiAgentParams``src/agents/pi-embedded-runner/run/params.ts`
Thread `jobId` to both hook contexts in `runCliAgent` (gate + post-run)`src/agents/cli-runner.ts`
Thread `jobId` to hookCtx in `runEmbeddedPiAgent``src/agents/pi-embedded-runner/run.ts`
Pass `jobId: params.job.id` from cron run-executor (CLI + embedded paths)`src/cron/isolated-agent/run-executor.ts`

Strict superset of existing behavior:

  • All call sites without `jobId` continue to work unchanged.
  • Non-cron flows leave `jobId` undefined.
  • Existing plugins are unaffected — they ignore the new optional field.

Tests

  • new: cron run with explicit `jobId` reaches the `before_agent_reply` hook context with that value.
  • new: non-cron run (`trigger: "user"`) does not invoke the `before_agent_reply` gate (regression guard for the existing cron-only invocation rule).

8/8 tests pass in `cli-runner.before-agent-reply-cron.test.ts`. Lint clean (`pnpm oxlint` — 0 warnings, 0 errors).

Acceptance criteria from issue

  • ✅ `PluginHookAgentContext` supports optional `jobId`
  • ✅ cron-triggered `before_agent_reply` calls populate `jobId`
  • ✅ existing behavior is unchanged for non-cron runs

🤖 generated with assistance from Claude Code Co-authored-by: HCL [email protected]

Changed files

  • src/agents/cli-runner.before-agent-reply-cron.test.ts (modified, +33/-0)
  • src/agents/cli-runner.ts (modified, +2/-0)
  • src/agents/cli-runner/types.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run/params.ts (modified, +2/-0)
  • src/cron/isolated-agent/run-executor.ts (modified, +2/-0)
  • src/plugins/hook-types.ts (modified, +8/-0)

PR #2: Expose cron jobId in plugin hook context

Description (problem / solution / changelog)

Summary

Add optional jobId?: string to plugin hook agent context (PluginHookAgentContext) so plugins can match cron-triggered runs to their specific cron jobs.

Why

Plugins like OpenClaw Smart Cron need to distinguish which cron job triggered a before_agent_reply hook. Currently ctx.runId is the ephemeral execution/session ID — not the stable cron job ID. Plugins have to guess or match on fragile patterns.

Changes

  • src/agents/cli-runner/types.ts: Add jobId?: string to RunCliAgentParams
  • src/agents/pi-embedded-runner/run/params.ts: Add jobId?: string to RunEmbeddedPiAgentParams
  • src/agents/cli-runner.ts: Forward jobId in buildRunClaudeCliAgentParams
  • src/agents/cli-runner.before-agent-reply-cron.test.ts: Regression test for CLI runner cron context
  • src/agents/pi-embedded-runner/run.before-agent-reply-cron.test.ts: Regression test for embedded runner cron context

Risk Assessment

Low risk. The field is optional, backward-compatible, and only populated for cron-triggered runs. No execution/eval/privilege surface added.

CI Note

Existing CI failures on checks-fast-bundled, checks-node-agentic-commands, checks-node-agentic-plugins, checks-node-core, and checks-node-core-fast-support are pre-existing and unrelated to these changes. They affect plugin loader tests, CLI policy mutation tests, and channel setup tests — none of which touch hook context or the jobId field.

Closes: https://github.com/openclaw/openclaw/issues/71826

Changed files

  • src/agents/cli-runner.before-agent-reply-cron.test.ts (modified, +4/-3)
  • src/agents/cli-runner.spawn.test.ts (modified, +16/-0)
  • src/agents/cli-runner.ts (modified, +3/-0)
  • src/agents/cli-runner/types.ts (modified, +1/-0)
  • src/agents/harness/hook-context.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/run.before-agent-reply-cron.test.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run/params.ts (modified, +2/-0)
  • src/cron/isolated-agent/run-executor.ts (modified, +2/-0)
  • src/plugins/hook-types.ts (modified, +1/-0)

PR #71827: Expose cron jobId in plugin hook context

Description (problem / solution / changelog)

Summary

Expose stable cron jobId in plugin hook agent context for cron-triggered runs.

Today, before_agent_reply hooks receive runId, but for cron runs that is the execution id rather than the persistent cron job id. This makes it difficult for plugins to target a specific cron job reliably.

This patch keeps the change intentionally small:

  • add optional jobId?: string to PluginHookAgentContext
  • thread jobId through the agent harness hook context
  • populate it for cron-triggered CLI and embedded agent runs
  • add focused regression coverage for both runner paths

Why

agentId can be used as a coarse matcher, but it is not precise when multiple cron jobs share the same agent.

Providing jobId lets plugins match the stable cron identifier directly without parsing runId or depending on execution-id formats.

Notes

  • backward-compatible: jobId is optional
  • non-cron flows remain unchanged
  • no behavior change unless a plugin chooses to read jobId

Validation

Ran focused tests:

  • src/agents/cli-runner.before-agent-reply-cron.test.ts
  • src/agents/pi-embedded-runner/run.before-agent-reply-cron.test.ts

Changed files

  • src/agents/cli-runner.before-agent-reply-cron.test.ts (modified, +4/-3)
  • src/agents/cli-runner.spawn.test.ts (modified, +16/-0)
  • src/agents/cli-runner.ts (modified, +3/-0)
  • src/agents/cli-runner/types.ts (modified, +1/-0)
  • src/agents/harness/hook-context.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/run.before-agent-reply-cron.test.ts (modified, +2/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +1/-0)
  • src/agents/pi-embedded-runner/run/params.ts (modified, +2/-0)
  • src/cron/isolated-agent/run-executor.ts (modified, +2/-0)
  • src/plugins/hook-types.ts (modified, +1/-0)
RAW_BUFFERClick to expand / collapse

Summary

before_agent_reply plugin hooks for cron-triggered agent runs receive runId, but not the stable cron jobId.

For cron workflows, runId is the execution id (for example cron:<jobId>:<startedAt> or a manual execution id), not the persistent cron job identifier. That makes it hard for plugins to match a specific cron job reliably.

Why this matters

Plugins may want to apply logic to one cron job but not another, even when they share the same agent. Matching on agentId is only a coarse fallback.

A stable jobId in hook context would let plugins:

  • target a specific cron job precisely
  • avoid parsing opaque execution ids
  • distinguish multiple cron jobs that use the same agent

Current behavior

Hook context includes values like:

  • runId
  • agentId
  • sessionKey
  • sessionId
  • trigger

But it does not include the cron jobId, even though cron execution code already has access to it upstream.

Proposed change

Add optional jobId?: string to PluginHookAgentContext and populate it for cron-triggered agent runs.

This keeps the change small and backward-compatible:

  • non-cron flows can continue leaving it undefined
  • existing plugins are unaffected
  • cron-aware plugins can opt into matching by stable job id

Suggested acceptance criteria

  • PluginHookAgentContext supports optional jobId
  • cron-triggered before_agent_reply calls populate jobId
  • existing behavior is unchanged for non-cron runs

extent analysis

TL;DR

To fix the issue, add an optional jobId field to the PluginHookAgentContext and populate it with the stable cron job identifier for cron-triggered agent runs.

Guidance

  • Modify the PluginHookAgentContext interface to include an optional jobId?: string property.
  • Update the cron execution code to populate the jobId field in the PluginHookAgentContext for cron-triggered agent runs.
  • Ensure that non-cron flows leave the jobId field undefined to maintain backward compatibility.
  • Verify that existing plugins are unaffected by the change and that cron-aware plugins can opt into matching by stable job ID.

Example

interface PluginHookAgentContext {
  // ... existing properties
  jobId?: string; // add optional jobId property
}

Notes

The proposed change is small and backward-compatible, allowing existing plugins to continue functioning without modification.

Recommendation

Apply the proposed change to add the optional jobId field to the PluginHookAgentContext, as it provides a precise way for plugins to target specific cron jobs without relying on parsing opaque execution IDs.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#inference speed#output truncation#response parsing#generation error#database connection

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Expose stable cron jobId in plugin hook context [3 pull requests, 3 comments, 2 participants]