Hi, (Agent mode leak) again

[simple fern]

Uh no . After one message it fall back into that meta mode https://www.answeroverflow.com/m/1505526600249245849?focus=1505534780903788607
It's not solved can i go back to the initial threat?

[candid edge]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[sullen compass]

Yep, go back to the original thread if it’s the same issue. Keeping it in one Answer Overflow thread is better than splitting the debugging trail.

Since it falls back into that meta/agent-mode state after one message, please add these in the original thread:

openclaw --version
openclaw status --all
A short log snippet from right after the fallback happens, ideally from openclaw logs --follow

Also: don’t mark it solved yet. If this keeps reproducing on the current version, it’s probably worth turning into a GitHub issue once the thread has the version + logs: https://github.com/openclaw/openclaw/issues

Docs for the quick debug commands: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken

[simple fern]

openclaw --version
OpenClaw 2026.5.12
accordiang to another bot of mine, it's somehow a known error. All actions are piped through a js sandbox now, which is controlled via scripts. Local agents complain they miss the return value. This is an oldstyle example in the context exec_command({cmd: "cat README.md"}) , this is a new example const result = await tools.exec_command({cmd: "cat memory/2026-05-17.md"});
text(result.output).

[sullen compass]

Thanks, 2026.5.12 helps.

That explanation sounds plausible, but I’d phrase it as “tool-call ABI / prompt mismatch” rather than definitely solved. If the agent has old tool examples in its context like exec_command({ ... }), it can get stuck imitating that instead of using the newer JS-wrapper shape:

const result = await tools.exec_command({ cmd: "cat README.md" });
text(result.output);

Things I’d try, in order:

1. Start a fresh session/thread for that agent, because the broken old tool instructions may already be in the transcript.
2. Search your agent/workspace instructions for stale examples: exec_command({, openclaw_browser({, etc. If they’re examples meant for the agent, rewrite them to the await tools.<name>(...) + text(...) style or remove them.
3. Restart the gateway after changing instructions/session state.
4. If it still happens, paste openclaw status --all and the log lines around the first fallback from openclaw logs --follow into the original thread.

Also note: if this is with a local/Ollama-style model, those are much more likely to drift into visible tool/meta text instead of making real tool calls. That doesn’t mean your config is wrong; it means we need logs + model/runtime info before calling it an OpenClaw bug.

[sullen compass]

Docs for the diagnostic commands: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken

[simple fern]

Changed instruc5tion but this is the feedbback of a running bot:
can’t continue yet—the exec runtime itself is currently broken. Every attempt to launch even a
trivial script (for example text("hi"); or 1+1;) immediately fails before execution with SyntaxError:
Unexpected token '}'.

but diagnostics are still fine.

[sullen compass]

That’s a different failure than the old exec_command({ ... }) example problem.

If even text("hi"); or 1+1; fails with SyntaxError: Unexpected token '}' before execution, the JS wrapper being handed to the exec runtime is malformed. Diagnostics can still be fine because openclaw status / doctor do not exercise the agent’s tool-call JS sandbox path.

Two important bits:

1. Changing instructions usually won’t fix a bot that is already in a poisoned running session. Stop that run/session and start a fresh one after the instruction change.
2. If a fresh session still throws the same syntax error on text("hi");, that’s issue-worthy. Please capture the exact stack/log line around the failure with:

openclaw logs --follow

Then include: