openclaw - 💡(How to fix) Fix [Bug]: Browser gateway chat run fails at runtime with ENOENT: mkdir '/home/node' after successful device-authenticated WebSocket connect [2 comments, 2 participants]

Error: ENOENT: no such file or directory, mkdir '/home/node'

This happens after:

• successful browser device auth • successful hello-ok • valid gateway request framing • accepted chat.send request with status: started

So the failure appears to be in the runtime/session bootstrap path, not in browser auth or WebSocket protocol handling.

Version / Environment

• OpenClaw version: 2026.3.22 • Node: v24.14.0 • Runtime host: Linux containerized OpenClaw environment • Browser page served from localhost on macOS • Gateway URL: ws://127.0.0.1:18789

Relevant config:

• agents.defaults.workspace = /home/node/.openclaw/workspace

What works

The following are verified working:

1. Browser connects to gateway WebSocket
2. Gateway sends connect.challenge
3. Browser responds with valid device identity + signature
4. Gateway returns hello-ok
5. Gateway emits normal events like health and tick
6. chat.send request framing is accepted
7. Gateway responds with:

JSON   { "ok": true, "payload": { "runId": "...", "status": "started" } }

What fails

Immediately after the accepted chat.send, the run fails with:

copy   Error: ENOENT: no such file or directory, mkdir '/home/node'

Reproduction

Browser-side repro

1. Serve a standalone HTML page from localhost
2. Connect to gateway over WS
3. Complete browser device-identity handshake
4. Wait for hello-ok
5. Send a prompt using chat.send
6. Observe successful run start followed by runtime failure:

copy   Error: ENOENT: no such file or directory, mkdir '/home/node'

Request path

The browser client uses:

• proper type: "req" • method: "chat.send" • valid params

This is not a malformed request issue.

Session-key variants tested

The failure reproduces with:

• ad hoc custom session key • gateway-provided main/default session key (agent:main:main, later main)

So this does not appear limited to custom session naming.

Related observations

• A cron job (Vehicle Scout) was fixed structurally by moving from: • sessionTarget: isolated to: • session:vehicle-scout • That suggests some persistent named session paths avoid the broken bootstrap path. • Other flows still intermittently show the same /home/node error, including a voice-note watcher cron job. • Separate log noise also showed occasional cron store parse errors, but that appears secondary.

Expected behavior

After successful gateway auth and accepted chat.send, the run should execute using the configured workspace:

Bash   /home/node/.openclaw/workspace

and should not attempt to mkdir '/home/node'.

Actual behavior

OpenClaw accepts the run, then fails immediately with:

copy   Error: ENOENT: no such file or directory, mkdir '/home/node'

Likely area to inspect

This appears to be in one of:

• browser-originated run bootstrap • session creation / resume path after chat.send • workspace resolution / ensure-agent-workspace path • divergence between persistent named session handling vs browser/main-session handling

Why this looks like a runtime bug

Ruled out already:

• missing device identity • invalid device signature • bad WS framing • bad chat.send envelope • missing configured workspace

The browser client authenticates successfully and the run is accepted before failing.

Extra note I created a standalone repro HTML page during testing. The browser/gateway auth layer works; the failure is downstream in runtime bootstrap. If useful, I can share a reduced repro flow, but the critical issue is reproducible from any browser client that successfully reaches chat.send and starts a run.

Steps to reproduce

1. Start OpenClaw 2026.3.22 with agents.defaults.workspace set to /home/node/.openclaw/workspace.
2. Serve a standalone browser page from localhost and connect it directly to the Gateway over WebSocket (ws://127.0.0.1:18789).
3. Complete the browser device-identity handshake successfully and confirm the Gateway returns hello-ok.
4. Send a prompt using chat.send with a valid request frame (type: "req", method: "chat.send", valid params).
5. Observe that the run is accepted with status: started.
6. Observe that the run then fails with Error: ENOENT: no such file or directory, mkdir '/home/node'.

Expected behavior

After successful browser Gateway authentication and an accepted chat.send request, OpenClaw should execute the run using the configured workspace at /home/node/.openclaw/workspace and return normal assistant response events instead of attempting to create /home/node.

Actual behavior

The browser client authenticates successfully, chat.send is accepted, and the Gateway returns status: started, but the run immediately fails with Error: ENOENT: no such file or directory, mkdir '/home/node'.

OpenClaw version

2026.3.22

Operating system

macOS host browser + Linux containerized OpenClaw runtime

Install method

docker

Model

openai-codex/gpt-5.4

Provider / routing chain

OpenClaw Gateway -> OpenAI Codex

Additional provider/model setup details

Issue does not appear model-specific. Browser authenticates to Gateway successfully and chat.send is accepted before the runtime fails during session/bootstrap workspace handling.

Logs, screenshots, and evidence

TL;DR

The most likely fix is to ensure the agents.defaults.workspace path is correctly resolved and accessible during runtime, as the error suggests an issue with creating the directory /home/node instead of using the configured workspace /home/node/.openclaw/workspace.

Guidance

1. Verify Workspace Configuration: Confirm that the agents.defaults.workspace configuration is correctly set to /home/node/.openclaw/workspace and that this path exists and is writable in the Linux containerized OpenClaw environment.
2. Check Directory Permissions: Ensure that the user running the OpenClaw process has the necessary permissions to create directories and write files in the /home/node/.openclaw/workspace directory.
3. Inspect Session Creation: Investigate the session creation or resume path after chat.send to identify why the workspace resolution might be failing, leading to an attempt to create /home/node instead of using the configured workspace.
4. Review Runtime Bootstrap: Examine the runtime bootstrap process to determine if there's a divergence in handling persistent named sessions versus the main session, as hinted by the success of the Vehicle Scout cron job after structural changes.

Example

No specific code example is provided due to the lack of direct code references in the issue, but ensuring correct path configuration and permissions is key.

Notes

The issue seems to be related to the runtime environment and session handling rather than the browser authentication or WebSocket protocol. The fact that some cron jobs have been fixed by changing session handling suggests that the problem might be related to how sessions are created or resumed after a chat.send request.

Recommendation

Apply a workaround by manually ensuring the workspace directory exists and is writable before starting the OpenClaw process, or modify the configuration to use a different workspace path that is known to be accessible. This should help mitigate the issue until the root cause can be fully identified and fixed.

FAIL-SAFE

Given the information, the safest approach is to verify the configuration and environment setup without making assumptions about the code or underlying system beyond what is explicitly stated in the issue.