Summary

• Problem: cron jobs could persist or reuse human direct-message session keys when sessionTarget="current" or session:<id> pointed at a real DM session.
• Why it matters: cron runs could write back into live Feishu/Lark direct chats, pollute those sessions, and contribute to silent/misdirected replies.
• What changed: add a small cron session-target guard during normalization, pass session context through tool/gateway update paths, and fall back to cron:<jobId> at runtime for legacy dirty direct targets.
• What did NOT change (scope boundary): group/channel/topic/thread sessions still reuse safely, non-channel named sessions still work, and cron schema/types/docs were not broadened.

Maintainer context: CODEOWNERS should route this through @openclaw/secops; @tyler6204 may also want a look for cron behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: cron normalization treated sessionTarget="current" as “persist the current session key” without checking whether that session key belonged to a human direct-message chat, and runtime execution later trusted any persisted session:<id> target unconditionally.
• Missing detection / guardrail: there was no eligibility guard for reusable direct-channel sessions at create/update time, and no runtime safety fallback for already-saved dirty jobs.
• Prior context (git blame, prior PR, issue, or refactor if known): current/session-bound cron persistence already existed in src/cron/normalize.ts; this change adds the missing direct-session boundary without changing the public schema.
• Why this regressed now: once cron started supporting current and persistent session:<id> bindings for agent turns, direct chat sessions became eligible by accident.
• If unknown, what was ruled out: ruled out schema/type mismatches and session-store lookup requirements; the bug reproduces from session-key normalization/execution alone.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/cron/normalize.test.ts, src/agents/tools/cron-tool.test.ts, src/gateway/server.cron.test.ts
• Scenario the test should lock in: direct-chat current bindings degrade to isolated on add/update, explicit dirty direct session:<id> jobs fall back to cron:<jobId> at runtime, and safe group/named session reuse stays intact.
• Why this is the smallest reliable guardrail: the bug spans normalization, tool/gateway seams, and runtime execution; these three layers cover the full path without adding heavy end-to-end setup.
• Existing test that already covers this (if any): existing cron normalization/runtime coverage existed, but none asserted the direct-session boundary.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• sessionTarget="current" now only persists safe reusable sessions; human direct-message sessions fall back to isolated.
• Explicit session:agent:...:direct:... targets are downgraded on create/update and ignored at runtime for legacy dirty jobs.
• Safe group/channel/topic/thread reuse and non-channel named sessions continue to work as before.

Diagram (if applicable)

Before:
[current or session:direct] -> [persist real DM session key] -> [cron run writes into human DM]

After:
[current direct] -> [normalize to isolated]
[legacy session:direct] -> [runtime fallback to cron:<jobId>] -> [isolated cron run]
[safe group/named session] -> [reuse preserved]

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): Yes
• If any Yes, explain risk + mitigation: this reduces cron's data-access scope by preventing reuse of human direct-message sessions. Risk is limited to stricter isolation; mitigation is a runtime warn-and-fallback path plus tests preserving safe group/named-session reuse.

Repro + Verification

Environment

• OS: macOS (local workstation)
• Runtime/container: Node.js v24.14.0, pnpm 10.32.1
• Model/provider: N/A
• Integration/channel (if any): Feishu/Lark-style direct session keys and Discord-style group session keys
• Relevant config (redacted): default local test config / mocked gateway test harness

Steps

1. Create an agent-turn cron job from a direct chat with sessionTarget="current".
2. Update the job (tool path and direct gateway RPC path) with sessionTarget="current" again.
3. Force-run a legacy dirty job persisted with sessionTarget="session:agent:...:direct:...".

Expected

• Add/update persist isolated instead of the human DM session.
• Legacy dirty jobs run in cron:<jobId> instead of the human DM session.
• Safe group/named session reuse is unchanged.

Actual

• Verified locally with new unit/integration coverage.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: targeted vitest coverage for normalize/tool/gateway runtime passed; pnpm build passed; pnpm check passed.
• Edge cases checked: explicit direct session:<id> downgrade, current downgrade from direct chats, safe group reuse, named-session preservation when the name merely contains direct.
• What you did not verify: full pnpm test is not green locally on this machine because unrelated existing failures remain in test/extension-test-boundary.test.ts and src/media-understanding/media-understanding-misc.test.ts, and one large unit batch hit a worker/OOM infrastructure failure.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: a named session that mimics an internal agent-scoped direct-session key could now be treated as unsafe.
  • Mitigation: the guard only treats canonical agent-scoped direct chat keys as unsafe, and tests preserve ordinary named sessions.
• Risk: legacy dirty jobs silently switching sessions could surprise operators.
  • Mitigation: runtime now emits a warning and falls back to the dedicated cron:<jobId> session instead of a human DM.