openclaw - ✅(Solved) Fix [Bug]: Cron isolated session ignores agentId workspace, falls back to main workspace [1 pull requests, 1 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#65075Fetched 2026-04-12 13:25:44
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
closed ×1cross-referenced ×1

When a cron job uses sessionTarget: "isolated" with payload.kind: "agentTurn" and agentId: "yinze", the isolated session is supposed to use the sub-agent's workspace (e.g. workspace-yinze/). However, the isolated session actually bootstraps from the main agent's workspace (~/.openclaw/workspace/), completely ignoring the agentId.

This causes the agent to fail to read workspace-specific files like SOW.md, AGENTS.md, and other bootstrap files that exist only in the sub-agent's workspace.

Error Message

Evidence: The cron run error log shows:

Root Cause

When a cron job uses sessionTarget: "isolated" with payload.kind: "agentTurn" and agentId: "yinze", the isolated session is supposed to use the sub-agent's workspace (e.g. workspace-yinze/). However, the isolated session actually bootstraps from the main agent's workspace (~/.openclaw/workspace/), completely ignoring the agentId.

This causes the agent to fail to read workspace-specific files like SOW.md, AGENTS.md, and other bootstrap files that exist only in the sub-agent's workspace.

Fix Action

Workaround

Embed full file contents or absolute paths directly in the cron message field instead of relying on workspace file discovery.

PR fix notes

PR #65085: fix(cron): preserve isolated agent workspace on reload

Description (problem / solution / changelog)

Fixes #65075

What changed

  • keep an explicit cron agentId when the hot-reloaded config snapshot no longer includes that agent entry
  • merge the matching agent entry from the gateway cron service config into the runtime config before launching the isolated run
  • add a regression test for isolated cron jobs whose startup config knows the sub-agent workspace while the reloaded config only knows main

Why

Gateway cron resolves jobs against a freshly loaded config on each run. If that snapshot no longer included the requested sub-agent, the job was silently demoted to the default agent and the isolated run bootstrapped from the main workspace instead of the sub-agent workspace.

Validation

  • pnpm vitest run src/gateway/server-cron.test.ts
  • pnpm lint src/gateway/server-cron.ts src/gateway/server-cron.test.ts

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/gateway/server-cron.test.ts (modified, +184/-0)
  • src/gateway/server-cron.ts (modified, +51/-11)

Code Example

⚠️ 📖 Read: from ~\.openclaw\workspace\SOW.md failed
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

When a cron job uses sessionTarget: "isolated" with payload.kind: "agentTurn" and agentId: "yinze", the isolated session is supposed to use the sub-agent's workspace (e.g. workspace-yinze/). However, the isolated session actually bootstraps from the main agent's workspace (~/.openclaw/workspace/), completely ignoring the agentId.

This causes the agent to fail to read workspace-specific files like SOW.md, AGENTS.md, and other bootstrap files that exist only in the sub-agent's workspace.

Steps to reproduce

  1. Create a sub-agent workspace at ~/.openclaw/workspace-yinze/ with an AGENTS.md and SOW.md
  2. Configure a cron job with sessionTarget: "isolated", payload.kind: "agentTurn", and agentId: "yinze"
  3. Trigger the cron job
  4. Observe: the isolated session loads bootstrap files from ~/.openclaw/workspace/ (main's workspace), not ~/.openclaw/workspace-yinze/

Expected behavior

The isolated session should use the workspace associated with agentId: "yinze", i.e. ~/.openclaw/workspace-yinze/. The agent should be able to read SOW.md from workspace-yinze/.

Actual behavior

The isolated session bootstraps from ~/.openclaw/workspace/ (main's workspace). When the agent tries to read SOW.md, it reads from ~\.openclaw\workspace\SOW.md (which may not exist or may be the wrong file), instead of workspace-yinze\SOW.md.

Evidence: The cron run error log shows:

⚠️ 📖 Read: from ~\.openclaw\workspace\SOW.md failed

The agent startup logs show it loaded AGENTS.md from the main workspace (317k+ input tokens loaded), confirming the wrong workspace was used.

Impact and severity

Severity: High — Makes sessionTarget: "isolated" + agentId combination unreliable for sub-agent cron jobs. The workaround is to use absolute file paths in cron messages (e.g. C:\Users\...\workspace-yinze\SOW.md), but this is fragile and not portable.

Workaround

Embed full file contents or absolute paths directly in the cron message field instead of relying on workspace file discovery.

Related issues

Issues #52806, #64497, #40692 all involve sessionTarget: "isolated" sessions behaving incorrectly. This appears to be a systemic workspace routing issue with isolated sessions when combined with agentId.

extent analysis

TL;DR

The isolated session should be configured to use the correct workspace associated with the provided agentId by ensuring the sessionTarget and agentId are properly linked to the sub-agent's workspace.

Guidance

  • Verify that the agentId is correctly mapped to the sub-agent's workspace (~/.openclaw/workspace-yinze/) in the configuration.
  • Check the cron job configuration to ensure that sessionTarget: "isolated" and payload.kind: "agentTurn" are correctly set and that agentId: "yinze" is properly referenced.
  • Consider using absolute file paths in the cron message field as a temporary workaround until the root cause is resolved.
  • Review related issues (#52806, #64497, #40692) to see if they provide any insight into the systemic workspace routing issue with isolated sessions.

Example

No code snippet is provided as the issue does not explicitly mention any specific code that needs to be changed.

Notes

The root cause of the issue appears to be a systemic problem with how isolated sessions handle workspaces when combined with agentId. The provided workaround may not be portable and is considered fragile.

Recommendation

Apply the workaround of using absolute file paths in the cron message field until the root cause of the systemic workspace routing issue is resolved and a more permanent fix can be implemented. This is because the current workaround, although fragile, provides a temporary solution to the high-severity issue affecting the reliability of sessionTarget: "isolated" + agentId combinations for sub-agent cron jobs.

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…

FAQ

Expected behavior

The isolated session should use the workspace associated with agentId: "yinze", i.e. ~/.openclaw/workspace-yinze/. The agent should be able to read SOW.md from workspace-yinze/.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING