openclaw - 💡(How to fix) Fix Beta blocker: codex - SSH-backed sandbox routing lost; app-server unconditionally strips exec/process from OpenClaw dynamic tools (#80048 regression) [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

Yes

Summary

PR #80048 (in 2026.5.10-beta.1) makes the Codex app-server dynamic-tool filter unconditionally strip read, write, edit, apply_patch, exec, process, and update_plan from the OpenClaw tool surface, with no remaining config knob to opt back in. Agents configured with tools.exec.host: "sandbox" and a non-default sandbox.backend (e.g. ssh) lose the only tool path that honored that routing, so all shell calls fall through to codex-cli's native bash, which runs in codex-cli's local bwrap and bypasses agents.list[].sandbox.backend entirely.

Steps to reproduce

1. Define an agent in agents.list[] running under the codex agentRuntime with a non-default sandbox backend, e.g.:

   {
     "id": "<redacted-remote-agent>",
     "sandbox": { "mode": "all", "backend": "ssh", "ssh": { /* redacted */ } },
     "tools": { "exec": { "host": "sandbox" } }
   }

2. On 2026.5.10-beta.1 (or any build containing PR #80048), start a session for that agent and ask it to run any shell command intended for the remote target.
3. Inspect the session's <sessionFile>.codex-app-server.json dynamicToolsFingerprint, and the rollout log tool_call entries.

Expected behavior

OpenClaw exec / process tools are advertised on the codex app-server's dynamic tool surface so the model can route shell calls through the configured sandbox.backend: "ssh" and reach the remote target. Restoring this previously required codexDynamicToolsProfile: "openclaw-compat".

Actual behavior

• dynamicToolsFingerprint does not include exec or process — they are stripped unconditionally by CODEX_APP_SERVER_OWNED_DYNAMIC_TOOL_EXCLUDES in extensions/codex/src/app-server/dynamic-tool-profile.ts.
• The model uses codex-cli's native bash, which runs in codex-cli's local bwrap; commands intended for the remote SSH target execute inside the OpenClaw container instead.
• codexDynamicToolsProfile: "openclaw-compat" is rejected by the new schema (extensions/codex/src/app-server/config.test.ts adds "rejects the retired dynamic tool profile key" returning {}), and openclaw doctor --fix actively deletes the key from existing configs.
• codexDynamicToolsExclude is additive only.

OpenClaw version

2026.5.10-beta.1 (last known good: 2026.5.7 with codexDynamicToolsProfile: "openclaw-compat")

Operating system

Ubuntu 24.04

Install method

docker (ghcr.io/openclaw/openclaw:latest)

Model

openai/gpt-5.5

Provider / routing chain

openclaw -> codex app-server (managed @openai/codex) -> openai-codex OAuth

Additional provider/model setup details

Default codex agentRuntime; appServer.mode: "guardian"; features.shell_tool=false set via -c to suppress the duplicate codex-native shell when on 2026.5.7. The features.shell_tool=false workaround is also affected, because under PR #80048 there is no longer a way to keep OC's exec/process advertised after disabling codex-native shell — leaving the agent with no shell-style tool at all.

Logs, screenshots, and evidence

PR #80048 own verification probe (from the PR description):

$ pnpm exec tsx -e '<filterCodexDynamicTools probe>'
input:  ["read","write","edit","apply-patch","bash","process","update_plan","browser.open","custom_tool"]
kept:   ["browser.open","custom_tool"]

PR #80048 extensions/codex/src/app-server/run-attempt.test.ts rewrite (was → is):

- "allows Codex dynamic tool filtering to opt back into OpenClaw compatibility"
-   { codexDynamicToolsProfile: "openclaw-compat", codexDynamicToolsExclude: ["custom_tool"] }
-   .toEqual(["read", "exec", "message"]);
+ "applies additional Codex dynamic tool excludes without exposing Codex-native tools"
+   { codexDynamicToolsExclude: ["custom_tool"] }
+   .toEqual(["message"]);

Impact and severity

• Affected: every agents.list[] entry that uses tools.exec.host: "sandbox" with a non-default sandbox.backend (today: any SSH-backed agent) under the codex agentRuntime.
• Severity: blocks the workflow — there is no remaining configuration that restores remote shell execution for the affected agents.
• Frequency: every shell call by the affected agent.
• Consequence: shell commands targeting the remote host execute inside the OpenClaw container; remote-state operations silently no-op or error against the wrong filesystem.

Additional information

• Last known good: 2026.5.7 (with explicit codexDynamicToolsProfile: "openclaw-compat").
• First known bad: 2026.5.10-beta.1 (PR #80048).
• Workarounds: (a) move affected agents off the codex agentRuntime to the PI / embedded harness; (b) stay on 2026.5.7 until upstream restores a per-agent or sandbox-backend-aware path.
• Suggested fix surfaces:
  • Per-agent codexDynamicToolsExclude that can both add and remove exclusions; or
  • Skip CODEX_APP_SERVER_OWNED_DYNAMIC_TOOL_EXCLUDES for agents.list[] entries whose sandbox.backend is non-default; or
  • Teach codex-cli's native bash tool to honor agents.list[].sandbox.backend, so the strip becomes harmless.
• Release risk: I believe this should block promoting 2026.5.10-beta.1 to stable because affected SSH-backed Codex agents silently execute shell commands in the wrong environment. This can look like success while mutating/reading the OpenClaw container instead of the intended remote target.