openclaw - ✅(Solved) Fix [Bug]: agents add wizard pre-fills nested workspace path (workspace/<id>) instead of documented peer-level (workspace-<id>) [2 pull requests, 1 comments, 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#71889Fetched 2026-04-27 05:37:47
View on GitHub
Comments
1
Participants
1
Timeline
3
Reactions
0
Participants
Timeline (top)
cross-referenced ×2labeled ×1

The interactive agents add <id> wizard pre-fills the "Workspace directory" prompt with a nested path under the main agent's workspace (~/.openclaw/workspace/<id>) instead of the peer-level form (~/.openclaw/workspace-<id>) documented in docs/concepts/multi-agent.md ("Paths quick map").

Users who hit Enter to accept the default end up with multi-agent layouts that violate the documented convention and cause silent footguns: main agent's recursive workspace operations leak into other agents' folders, and rm -rf ~/.openclaw/workspace to reset main also nukes every other agent's workspace.

Error Message

implications, no crash or visible error.

Root Cause

OpenClaw documents the workspace as "the default cwd, not a hard sandbox," so isolation is partly conventional. The peer-level layout (workspace/ and workspace-<id>/) preserves that convention because recursive operations rooted at workspace/ stay within main's tree.

Fix Action

Fixed

PR fix notes

PR #71899: fix(agents): keep added workspaces peer-level

Description (problem / solution / changelog)

Summary

  • Fix agents add workspace defaults so setup's main workspace directory is treated as the main agent workspace, not a shared base for new agents.
  • Preserve custom shared workspace bases, where non-default agents still resolve under the configured base.
  • Add regression coverage and a changelog entry for #71889.

Root Cause

openclaw setup stores the main workspace in agents.defaults.workspace. The agents add wizard asks resolveAgentWorkspaceDir() for the new agent's default, and the resolver appended non-default agent ids to any agents.defaults.workspace, including the setup-created main workspace. That produced nested paths like workspace/testbug instead of the documented peer-level workspace-testbug.

Why This Fix Is Safe

The resolver now only treats agents.defaults.workspace as a shared base when it differs from the normal main-agent workspace default. Explicit per-agent workspace values still win, default-agent resolution is unchanged, and intentionally custom bases such as /shared-ws/<agentId> keep the existing behavior.

Security / Runtime Controls

This changes the runtime workspace path resolver used by the CLI and Gateway paths; it does not rely on prompt text. Workspace sandboxing, fs-safe policy, workspace-only controls, and agent config authorization behavior are unchanged.

Self-Review

  • Test helper defaults match production defaults: the regression uses resolveAgentWorkspaceDir() with OPENCLAW_HOME to model setup's default main workspace.
  • Config defaults, schema help, and generated artifacts are unchanged; only the fallback interpretation changed.
  • Security posture is unchanged because this affects path selection, not sandbox policy or permission checks.

Tests

  • pnpm test src/agents/agent-scope.test.ts
  • pnpm test src/agents/agent-scope.test.ts src/commands/agents.add.test.ts src/infra/changelog-unreleased.test.ts
  • pnpm check:changed (failed in expanded agents test lane with Vitest worker OOM after 349/350 files passed; typecheck, lint, import-cycle, and guards passed)
  • OPENCLAW_VITEST_MAX_WORKERS=1 pnpm check:changed

Notes

  • AI-assisted: yes.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/concepts/multi-agent.md (modified, +2/-0)
  • src/agents/agent-scope-config.ts (modified, +25/-1)
  • src/agents/agent-scope.test.ts (modified, +91/-0)

PR #71941: fix(agents/wizard): pre-fill peer-level workspace path on agents add for documented default

Description (problem / solution / changelog)

Fixes #71889.

Root cause

openclaw setup writes agents.defaults.workspace = ~/.openclaw/workspace on first run. When the operator later runs openclaw agents add <id>, the wizard's "Workspace directory" prompt seeds initialValue from resolveAgentWorkspaceDir(cfg, agentId). For non-default agents that path resolves to path.join(defaults.workspace, id) (set by #59789) — i.e. ~/.openclaw/workspace/<id>, nested under the main agent's tree, not the peer-level ~/.openclaw/workspace-<id> documented in docs/concepts/multi-agent.md:57,67.

If the operator hits Enter, the nested layout becomes the persisted reality:

  • Skill discovery walking ~/.openclaw/workspace/skills/ traverses <other-agent>/skills/ along with main's, leaking cross-agent skills under OpenClaw's "soft sandbox" model.
  • rm -rf ~/.openclaw/workspace to reset main wipes every nested agent's workspace, memory, and skills.
  • Recursive memory/grep/glob inside main's workspace silently treats other agents' private files as main's.

Fix

src/agents/agent-scope-config.ts — add suggestPeerAgentWorkspaceDir(cfg, id, env). The helper only overrides runtime resolution in the narrow post-setup scenario where agents.defaults.workspace exactly matches resolveDefaultAgentWorkspaceDir(env) (the value the setup wizard wrote). In that case it returns the documented peer-level form ~/.openclaw/workspace-<id>. Every other shape — unset defaults.workspace, custom shared roots like /srv/agents, /srv/workspace, /srv/workspace-prod, and OPENCLAW_STATE_DIR-isolated multi-gateway setups — defers to resolveAgentWorkspaceDir so the contracts from #59789 (shared-base nesting) and per-instance state-dir isolation stay intact.

src/commands/agents.commands.add.ts — the wizard uses the new helper as initialValue only for brand-new agents. When openclaw agents add <existing-id> is used to update an existing agent, the prompt still seeds from resolveAgentWorkspaceDir(cfg, agentId) so a pressed-Enter on a routine auth/binding update does not silently relocate the agent.

Runtime resolution via resolveAgentWorkspaceDir is intentionally unchanged. Existing per-agent workspace overrides take precedence, and the #59789 nested layout is preserved for everyone who explicitly configured it.

Verification

  • node standalone trace through 8 representative configs (default install, OPENCLAW_PROFILE, OPENCLAW_STATE_DIR isolation, /srv/agents shared root, /srv/workspace and /srv/workspace-prod ambiguous bases, /shared-ws #59789, id normalization) — all behave as expected.
  • Added 6 unit tests in agent-scope.test.ts covering each scenario above and 2 wizard tests in agents.add.test.ts covering both new-agent prefill and existing-agent update paths.
  • oxfmt --check and npx oxlint clean on changed files.
  • pnpm tsgo:core produces the same set of pre-existing unrelated errors as c070509b7f (verified by stashing and re-running on clean main).
  • 4 review iterations with codex review --base origin/main against this diff. Final pass: "I did not identify any blocking correctness issues in the diff."

Test plan

  • Unit tests added for the new helper covering all 6 documented config shapes.
  • Wizard tests for both new-agent and existing-agent update paths.
  • Codex review clean.
  • Manual pnpm openclaw agents add testbug on a fresh ~/.openclaw to confirm the prompt prefill matches expectations.
  • Manual pnpm openclaw agents add <existing-id> on a config with a customized agent workspace to confirm the prefill preserves it.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/agent-scope-config.ts (modified, +40/-0)
  • src/agents/agent-scope.test.ts (modified, +65/-0)
  • src/agents/agent-scope.ts (modified, +1/-0)
  • src/commands/agents.add.test.ts (modified, +68/-0)
  • src/commands/agents.commands.add.ts (modified, +7/-1)

Code Example

Live wizard prompt (verbatim terminal output):

  $ pnpm openclaw agents add testbug

  > openclaw@2026.4.25 openclaw /Users/pushpendra/workspace/openclaw
  > node scripts/run-node.mjs agents add testbug

  🦞 OpenClaw 2026.4.25 (95b7a85)Ah, the fruit tree company! 🍎

Add OpenClaw agent
Workspace directory
/Users/<user>/.openclaw/workspace/testbug█

`agents list` output from a setup where the wizard's default was accepted:

  - agent-007
    Workspace: /home/node/.openclaw/workspace/agent-007
    Agent dir: /home/node/.openclaw/agents/agent-007/agent

---

Source-level observation:

src/agents/workspace.ts `resolveDefaultAgentWorkspaceDir()` only branches on 
OPENCLAW_PROFILE, never on the agent id from agents.list[]. The wizard 
handler in src/cli/program/register.agent.ts appears to take this default 
and append the agent id with `path.join(defaultWs, agentId)`, producing the 
nested layout instead of the documented `workspace-<agentId>` form.

Related issues (same code area, complementary fixes):
- #21770 — agents.list[].workspace override ignored at runtime
- #40334 — workspaceOnly: false ignored after gateway restart

Happy to prepare a PR if a maintainer can confirm preferred direction:
(a) Fix wizard to pre-fill workspace-<id> (peer-level), matching docs.
(b) Update docs to reflect current nested behavior.

I'd advocate (a) for ergonomics and consistency with existing 
agents/<id>/ peer-level layout.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The interactive agents add <id> wizard pre-fills the "Workspace directory" prompt with a nested path under the main agent's workspace (~/.openclaw/workspace/<id>) instead of the peer-level form (~/.openclaw/workspace-<id>) documented in docs/concepts/multi-agent.md ("Paths quick map").

Users who hit Enter to accept the default end up with multi-agent layouts that violate the documented convention and cause silent footguns: main agent's recursive workspace operations leak into other agents' folders, and rm -rf ~/.openclaw/workspace to reset main also nukes every other agent's workspace.

Steps to reproduce

  1. Clone openclaw/openclaw at recent main (tested on commit 95b7a85, version 2026.4.25):

    git clone https://github.com/openclaw/openclaw.git cd openclaw pnpm install

  2. With a configured ~/.openclaw/ already present (i.e. a "main" agent exists), run:

    pnpm openclaw agents add testbug

  3. Observe the value pre-filled into the "Workspace directory" prompt.

Expected behavior

Per docs/concepts/multi-agent.md ("Paths quick map"):

Workspace: ~/.openclaw/workspace (or ~/.openclaw/workspace-<agentId>)

agents add testbug should pre-fill:

~/.openclaw/workspace-testbug

producing the documented peer-level layout:

~/.openclaw/ ├── workspace/ # main agent ├── workspace-testbug/ # peer-level for new agent └── agents/ ├── main/ └── testbug/

This would also be consistent with ~/.openclaw/agents/<id>/, which IS already correctly peer-level.

Actual behavior

The wizard pre-fills a nested path:

┌ Add OpenClaw agent │ ◆ Workspace directory │ /Users/<user>/.openclaw/workspace/testbug█ ────────── ─────── main's WS appended id

Accepting this default produces:

~/.openclaw/ ├── workspace/ │ └── testbug/ ← nested under main (incorrect) └── agents/ ├── main/ └── testbug/ ← peer-level (correct)

Real-world artifact from a pre-existing setup confirms the same pattern is what gets persisted into config (agents list output):

  • main (default) Workspace: /home/node/.openclaw/workspace
  • agent-007 Workspace: /home/node/.openclaw/workspace/agent-007 ← NESTED

The agent-007 workspace literally became <main_workspace>/<agent-id>.

OpenClaw version

2026.4.25 (95b7a85)

Operating system

macOS 14.x (Apple Silicon, Mac mini) Node 24.x via fnm, pnpm 10.x Run via pnpm openclaw ... from source clone. OPENCLAW_PROFILE: not set

Install method

No response

Model

ollama/kimi-k2.6:cloud

Provider / routing chain

  • main (default) Model: ollama/kimi-k2.6:cloud

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Live wizard prompt (verbatim terminal output):

  $ pnpm openclaw agents add testbug

  > [email protected] openclaw /Users/pushpendra/workspace/openclaw
  > node scripts/run-node.mjs agents add testbug

  🦞 OpenClaw 2026.4.25 (95b7a85) — Ah, the fruit tree company! 🍎

  ┌  Add OpenClaw agent
  ◆  Workspace directory
  │  /Users/<user>/.openclaw/workspace/testbug█

`agents list` output from a setup where the wizard's default was accepted:

  - agent-007
    Workspace: /home/node/.openclaw/workspace/agent-007
    Agent dir: /home/node/.openclaw/agents/agent-007/agent

---

Source-level observation:

src/agents/workspace.ts `resolveDefaultAgentWorkspaceDir()` only branches on 
OPENCLAW_PROFILE, never on the agent id from agents.list[]. The wizard 
handler in src/cli/program/register.agent.ts appears to take this default 
and append the agent id with `path.join(defaultWs, agentId)`, producing the 
nested layout instead of the documented `workspace-<agentId>` form.

Related issues (same code area, complementary fixes):
- #21770 — agents.list[].workspace override ignored at runtime
- #40334 — workspaceOnly: false ignored after gateway restart

Happy to prepare a PR if a maintainer can confirm preferred direction:
(a) Fix wizard to pre-fill workspace-<id> (peer-level), matching docs.
(b) Update docs to reflect current nested behavior.

I'd advocate (a) for ergonomics and consistency with existing 
agents/<id>/ peer-level layout.

Impact and severity

Severity: Medium-to-High — silent footgun with security and data-loss implications, no crash or visible error.

Workspace boundary leakage (security)

OpenClaw documents the workspace as "the default cwd, not a hard sandbox," so isolation is partly conventional. The peer-level layout (workspace/ and workspace-<id>/) preserves that convention because recursive operations rooted at workspace/ stay within main's tree.

The buggy nested layout breaks this:

~/.openclaw/ └── workspace/ ← main agent's root ├── (main's files) ├── SOUL.md, AGENTS.md, etc. └── <other-agent>/ ← LIVES INSIDE main's root ├── SOUL.md ├── memory/ └── (private files)

Any tool or operation that recursively walks main's workspace — skill discovery, glob patterns, file search, memory aggregation, MEMORY.md distillation, workspace-scoped grep — will silently traverse into every other agent's folder and treat its private files as if they belonged to main. Other agents' SOUL.md, memory/, identity, and any cached secrets become readable by main without any explicit cross-agent permission.

This is not a hypothetical: agent skills are loaded from workspace/skills/, so a skill placed in any nested agent's folder may also be inadvertently loaded by the main agent's skill discovery. Cross- agent skill leakage is a privilege boundary violation even under OpenClaw's "soft sandbox" model.

Data-loss footgun

Common reset advice ("clear my main agent: rm -rf ~/.openclaw/workspace") silently destroys every nested agent's workspace, memory, and skills along with main's. Users have no warning because the layout looks single-tree.

User-experience inconsistency

~/.openclaw/agents/<id>/ is corre

Additional information

  • Reproduced on commit 95b7a85 of openclaw/openclaw at main, version 2026.4.25. Did not test other versions, so cannot bisect a regression range.

  • Originally observed via the third-party Docker image ghcr.io/phioranex/openclaw-docker:latest. The same buggy default appears in the wizard when run from a clean source clone, so the bug is in upstream OpenClaw rather than the Docker image.

  • The wizard's pre-fill is a default value the user can override by typing a different path. Users who type an explicit path (e.g. ~/.openclaw/workspace-myagent) avoid the bug. The issue is the default that most users will accept.

  • Adjacent code pointers (verified by inspection, not testing):

    • src/agents/workspace.ts: resolveDefaultAgentWorkspaceDir() handles the OPENCLAW_PROFILE branch but has no agent-id branch.
    • src/cli/program/register.agent.ts: agents add command handler (test file at register.agent.test.ts confirmed exists at this path).
  • Issue #21770 ("agents.list[].workspace override ignored") and #40334 ("workspaceOnly: false ignored after restart") touch the same workspace-resolution code path but report different symptoms. This bug is complementary to both, not a duplicate.

  • Not a regression report. I do not have a "last known good" version because I haven't bisected.

extent analysis

TL;DR

The issue can be fixed by modifying the resolveDefaultAgentWorkspaceDir() function in src/agents/workspace.ts to correctly handle the agent id and pre-fill the "Workspace directory" prompt with the peer-level path (~/.openclaw/workspace-<id>).

Guidance

  • The bug is caused by the resolveDefaultAgentWorkspaceDir() function not branching on the agent id, resulting in a nested path being pre-filled in the wizard.
  • To fix this, the function should be modified to handle the agent id and return the correct peer-level path.
  • The register.agent.ts file should also be updated to use the corrected resolveDefaultAgentWorkspaceDir() function.
  • The fix should be verified by running the agents add command and checking that the correct peer-level path is pre-filled in the wizard.

Example

// src/agents/workspace.ts
function resolveDefaultAgentWorkspaceDir(agentId: string) {
  // Return the peer-level path for the agent
  return `~/.openclaw/workspace-${agentId}`;
}

Notes

  • The fix assumes that the agentId is available in the resolveDefaultAgentWorkspaceDir() function.
  • The fix only addresses the specific issue reported and may not fix other related issues.

Recommendation

Apply the workaround by modifying the resolveDefaultAgentWorkspaceDir() function to correctly handle the agent id and return the peer-level path. This fix is preferred because it addresses the root cause of the issue and provides a consistent user experience.

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

Per docs/concepts/multi-agent.md ("Paths quick map"):

Workspace: ~/.openclaw/workspace (or ~/.openclaw/workspace-<agentId>)

agents add testbug should pre-fill:

~/.openclaw/workspace-testbug

producing the documented peer-level layout:

~/.openclaw/ ├── workspace/ # main agent ├── workspace-testbug/ # peer-level for new agent └── agents/ ├── main/ └── testbug/

This would also be consistent with ~/.openclaw/agents/<id>/, which IS already correctly peer-level.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING