openclaw - 💡(How to fix) Fix Main agent intermittently starts with wrong cwd and tries to read ~/.openclaw/agents/main/agent/AGENTS.md instead of workspace AGENTS.md [1 participants]

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

Main agent intermittently starts with cwd /home/elicw instead of the configured workspace /home/elicw/.openclaw/workspace, and then attempts to read /home/elicw/.openclaw/agents/main/agent/AGENTS.md instead of the workspace bootstrap file.

Steps to reproduce

NOT_ENOUGH_INFO

Expected behavior

The main agent should start with cwd matching the configured workspace /home/elicw/.openclaw/workspace, and bootstrap files like AGENTS.md should resolve from that workspace.

Actual behavior

Observed error from the main agent channel: read failed: ENOENT: no such file or directory, access '/home/elicw/.openclaw/agents/main/agent/AGENTS.md'. The affected broken session transcript shows it started with cwd="/home/elicw" in /home/elicw/.openclaw/agents/main/sessions/5389962d-2164-464b-b9ff-daff351cef8f.jsonl:1.

OpenClaw version

v2026.4.15

Operating system

Linux 6.6.87.2-microsoft-standard-WSL2 (WSL2)

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

Configured workspace in ~/.openclaw/openclaw.json is agents.defaults.workspace = "/home/elicw/.openclaw/workspace". In the observed failure, the affected main session used openai-codex/gpt-5.4. Healthy sessions in the same installation used cwd /home/elicw/.openclaw/workspace.

Logs, screenshots, and evidence

User-visible error: read failed: ENOENT: no such file or directory, access '/home/elicw/.openclaw/agents/main/agent/AGENTS.md' Broken session transcript: /home/elicw/.openclaw/agents/main/sessions/5389962d-2164-464b-b9ff-daff351cef8f.jsonl:1 shows {"type":"session",...,"cwd":"/home/elicw"} Verified workspace config: ~/.openclaw/openclaw.json agents.defaults.workspace = "/home/elicw/.openclaw/workspace" Local tracing shows ACP session metadata persistence includes cwd: ~/.npm-global/lib/node_modules/openclaw/dist/manager-CECGVjs9.js Local tracing also shows embedded ACPX runtime session initialization uses: cwd: input.cwd ?? this.options.cwd and canonicalizes with: path.resolve(input.cwd?.trim() || this.options.cwd) in ~/.npm-global/lib/node_modules/openclaw/dist/register.runtime-CHt9wXwu.js Workaround observed to fix behavior: forcing a fresh main session with /new restored normal behavior

Impact and severity

Affected: main agent direct/webchat session in this installation Severity: Medium to high (breaks normal use of the main agent when it tries to read bootstrap files from the wrong path) Frequency: Intermittent, observed at least once and cleared by resetting the session Consequence: Main agent can fail bootstrap-related file reads with ENOENT until a fresh session is created

Additional information

This appears to be session-state related rather than a bad workspace config. The configured workspace was correct during the incident, and the issue disappeared after forcing a fresh main session with /new. Local tracing suggests the likely root cause is embedded ACPX runtime cwd fallback or persisted cwd reuse: the ACP manager persists cwd from requestedCwd or handle.cwd, while the embedded ACPX runtime derives session cwd from input.cwd ?? this.options.cwd and canonicalizes it before persisting it into the runtime record. That makes it plausible that a generic cwd such as /home/elicw can be persisted into ACP session state and later reused by the main session even when the agent workspace is configured correctly.

Exact backend and origin The active ACP runtime backend is the embedded ACPX runtime, registered here:

~/.npm-global/lib/node_modules/openclaw/dist/register.runtime-CHt9wXwu.js around registerAcpRuntimeBackend({ id: ACPX_BACKEND_ID, ... })

Exact cwd origin chain

1. ACP manager passes requested cwd into backend File:

~/.npm-global/lib/node_modules/openclaw/dist/manager-CECGVjs9.js Key line:

runtime.ensureSession({ ..., cwd: requestedCwd }) 2. ACPX runtime forwards that cwd, or falls back to backend default File:

~/.npm-global/lib/node_modules/openclaw/dist/register.runtime-CHt9wXwu.js Inside AcpxRuntime.ensureSession(input):

cwd: input.cwd ?? this.options.cwd That is the first concrete backend-side fallback point.

1. ACPX runtime manager canonicalizes it into the record Same file, inside AcpRuntimeManager.ensureSession(input):

const cwd = path.resolve(input.cwd?.trim() || this.options.cwd); Then it creates/persists the session record with that exact cwd.

1. The handle returns persisted record cwd Still same file:

handle.cwd = record.cwd and the ACP manager later persists:

effectiveCwd = normalizeOptionalString(handle.cwd) ?? requestedCwd