Unchain Codex app-server harness defaults

[pashpashpash]

OpenAI models behave best in OpenClaw when the Codex app-server path can run like a trusted local Codex session. Before this change, the plugin defaulted native Codex to approvalPolicy: "on-request" and sandbox: "workspace-write". That conservative posture is a bad fit for unattended OpenClaw runs: heartbeats cannot see or answer native Codex approval prompts, and the workspace sandbox blocks the network and shell work heartbeat tasks need.

This flips the Codex app-server defaults to approvalPolicy: "never" and sandbox: "danger-full-access", updates the manifest and docs, and keeps existing explicit config/env overrides intact for people who want a tighter posture.

Evidence from the local branch:

• pnpm test extensions/codex/src/app-server/config.test.ts extensions/codex/src/app-server/run-attempt.test.ts passed with 2 files and 18 tests.
• pnpm check:changed passed in the commit hook with the extensions/docs lanes, 19 files, and 88 tests.
• pnpm build passed.
• I restarted the local Gateway on this branch and triggered a main-session heartbeat at 2026-04-22 01:39 PDT. The transcript recorded provider codex, model gpt-5.4, and the heartbeat ran pwd from /Users/pash/.openclaw/workspace plus curl -I https://example.com; both exited 0 and curl returned HTTP/2 200, with no native Codex permission block.
• A separate direct Codex run with session codex-policy-validation also reported fallbackUsed: false, provider codex, model gpt-5.4, 3 bash tool calls, 0 failures, and curl -I https://api.github.com returned HTTP/2 200.

[aisle-research-bot]

🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

#	Severity	Title
1	🟠 High	Codex harness defaults disable approvals and enable full-access sandbox (insecure-by-default)
2	🟠 High	Unauthenticated/unenforced remote Codex app-server WebSocket endpoint can drive privileged tool execution

1. 🟠 Codex harness defaults disable approvals and enable full-access sandbox (insecure-by-default)

Property	Value
Severity	High
CWE	CWE-250
Location	extensions/codex/src/app-server/config.ts:136-143

Description

The Codex harness now resolves runtime options with unsafe defaults:

• approvalPolicy defaults to "never", disabling native approval gating.
• sandbox defaults to "danger-full-access", granting broad host/network/shell access.

These defaults apply whenever the caller does not explicitly configure appServer.approvalPolicy/appServer.sandbox (or env overrides). If the Codex harness can be triggered by untrusted inputs (e.g., remote webchat/gateway users, CI jobs, shared multi-user hosts) or if an operator uses WebSocket transport to a reachable app-server, this configuration turns typical “agent tool use” into a practical RCE / privilege escalation path.

Vulnerable code (new defaults):

approvalPolicy: ... ?? "never",
sandbox: ... ?? "danger-full-access",

The plugin schema defaults were also changed to match, making these unsafe settings the default in configuration tooling/UX as well.

Recommendation

Make safe operation the default, and require explicit opt-in for unchained/full-access execution.

Recommended changes:

1. Restore safer defaults (or choose more restrictive ones):
   • approvalPolicy: "on-request" (or "untrusted" for more conservative behavior)
   • sandbox: "workspace-write" (or "read-only")
2. Add a hard guardrail: only allow sandbox: "danger-full-access" and/or approvalPolicy: "never" when an explicit allowDangerousDefaults: true (or similar) flag is set, and ideally only for stdio/local operation.

Example:

const approvalPolicy =
  resolveApprovalPolicy(config.approvalPolicy) ??
  resolveApprovalPolicy(env.OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY) ??
  "on-request";

const sandbox =
  resolveSandbox(config.sandbox) ??
  resolveSandbox(env.OPENCLAW_CODEX_APP_SERVER_SANDBOX) ??
  "workspace-write";

if ((approvalPolicy === "never" || sandbox === "danger-full-access") && !config.allowDangerous) {
  throw new Error("Refusing to run with unchained/full-access Codex defaults without explicit allowDangerous opt-in");
}

Also update extensions/codex/openclaw.plugin.json defaults to match the safe defaults so config generation/UI does not encourage unsafe settings.

2. 🟠 Unauthenticated/unenforced remote Codex app-server WebSocket endpoint can drive privileged tool execution

Property	Value
Severity	High
CWE	CWE-306
Location	extensions/codex/src/app-server/transport-websocket.ts:18-22

Description

The Codex gateway supports a websocket transport that connects to an arbitrary URL provided by plugin config/env. The connection does not require authentication (auth token is optional) and there is no validation of URL scheme/host (e.g., restricting to localhost/wss).

Because the app-server is a JSON-RPC peer that can:

• Control threadId/turnId values returned from thread/start and turn/start
• Send item/tool/call requests that are forwarded into toolBridge.handleToolCall(...)

…a malicious or user-controlled WebSocket endpoint can coerce the gateway into executing OpenClaw dynamic tools (file/workspace/host actions) in the current session context.

Vulnerable code:

const headers = {
  ...options.headers,
  ...(options.authToken ? { Authorization: `Bearer ${options.authToken}` } : {}),
};
const socket = new WebSocket(options.url, { headers });

Recommendation

Require explicit security controls for WebSocket transport:

• Require authentication when transport === "websocket" (e.g., make authToken mandatory) and fail closed if missing.
• Restrict endpoints by default (e.g., allow only wss:// and/or ws(s)://localhost unless an explicit allowRemoteWebsocket: true is set).
• Consider pinning to loopback/private ranges, and reject URL schemes other than ws:/wss:.

Example hardening in createWebSocketTransport / config resolution:

const u = new URL(options.url);
if (u.protocol !== "wss:" && u.protocol !== "ws:") throw new Error("Invalid scheme");
if (!options.authToken) throw new Error("authToken is required for websocket transport");
if (!(u.hostname === "localhost" || u.hostname === "127.0.0.1" || u.hostname === "::1")) {
  throw new Error("Remote websocket endpoints are not allowed by default");
}

---

Analyzed PR: #70082 at commit 80f9d5d

_{Last updated on: 2026-04-22T08:54:24Z}

[greptile-apps]

Greptile Summary

This PR flips the Codex app-server harness defaults from approvalPolicy: "on-request" / sandbox: "workspace-write" to approvalPolicy: "never" / sandbox: "danger-full-access", so unattended OpenClaw heartbeats can use network and shell tools without stalling on unanswerable native Codex approval prompts. The change is applied consistently across config.ts, the plugin manifest, docs, tests, and CHANGELOG, and existing explicit config/env overrides continue to take precedence over the new defaults.

Confidence Score: 5/5

Safe to merge — intentional, well-documented default change with consistent test coverage across all affected surfaces.

All six changed files are internally consistent: the runtime fallback in config.ts, the JSON schema defaults in openclaw.plugin.json, the documentation table, the tests in config.test.ts and run-attempt.test.ts, and the CHANGELOG all agree on the new defaults. No existing overrides are affected. No P0/P1 findings.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(codex): unchain app-server defaults" | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6359395b80

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep websocket sessions on constrained default policy

resolveCodexAppServerRuntimeOptions now unconditionally falls back to approvalPolicy: "never" and sandbox: "danger-full-access", so existing websocket deployments that only set transport/url silently become fully unchained. Because these values are forwarded on thread start/resume, remote app-server runs lose native approval gating and gain broader shell/network access compared with the previous defaults; this should be scoped to trusted local stdio runs (or require explicit opt-in) to avoid an unexpected privilege escalation for remote setups.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80f9d5db81

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Scope unchained defaults to stdio transport

These fallback values now apply to every app-server transport, so a websocket deployment that only sets appServer.transport: "websocket" (+ url) silently inherits approvalPolicy: "never" and sandbox: "danger-full-access" on thread start/resume/turn. That removes native approval gating and sandboxing for remote app-server sessions, which is a production safety regression compared with the previous defaults and is especially risky because it happens without explicit opt-in.

Useful? React with 👍 / 👎.