Description

The Codex app-server client spawns an external executable whose path and arguments are controlled by environment variables:

• OPENCLAW_CODEX_APP_SERVER_BIN controls the executable name/path (defaults to codex and therefore searches PATH).
• OPENCLAW_CODEX_APP_SERVER_ARGS controls the argument vector.
• The child process is launched with env: process.env, inheriting the full environment.

If an attacker can influence environment variables or PATH in the runtime (e.g., multi-tenant worker, CI, plugin host, or any scenario where untrusted users can affect the execution environment), they can:

• Execute an arbitrary binary by setting OPENCLAW_CODEX_APP_SERVER_BIN to a malicious path, or by placing a malicious codex earlier in PATH.
• Alter behavior via attacker-controlled args.

Vulnerable code:

const bin = process.env.OPENCLAW_CODEX_APP_SERVER_BIN?.trim() || "codex";
const extraArgs = splitShellWords(process.env.OPENCLAW_CODEX_APP_SERVER_ARGS ?? "");
const args = extraArgs.length > 0 ? extraArgs : ["app-server", "--listen", "stdio://"];
const child = spawn(bin, args, {
  env: process.env,
  stdio: ["pipe", "pipe", "pipe"],
});

Recommendation

Treat the spawned binary as a trusted dependency and prevent untrusted env/PATH from selecting it.

Recommended mitigations (pick what fits your threat model):

1. Require an absolute, allowlisted path (or ship/resolve a bundled binary):

import path from "node:path";

const configured = process.env.OPENCLAW_CODEX_APP_SERVER_BIN?.trim();
const bin = configured ? path.resolve(configured) : "/usr/local/bin/codex";
if (!bin.startsWith("/usr/local/bin/")) {
  throw new Error("Invalid OPENCLAW_CODEX_APP_SERVER_BIN");
}

2. Remove/limit env-controlled args; if customization is needed, validate against an allowlist of supported flags.

3. Do not pass the full environment. Pass only required variables:

const env = {
  PATH: process.env.PATH, // if needed
  HOME: process.env.HOME,
  ​// explicitly required OpenAI/Codex vars only
};
spawn(bin, args, { env, stdio: ["pipe","pipe","pipe"] });

4. In high-risk deployments, consider a configuration file with strict permissions instead of environment variables.

Description

The Codex app-server approval bridge only checks that an incoming approval request matches the current thread/turn when identifiers are present. If requestParams is missing or not a JSON object, matchesCurrentTurn() returns true, and the bridge proceeds to request a gateway approval and returns an approval decision for the current run.

This creates an authorization/scoping gap:

• Input: requestParams originates from the codex app-server RPC request (request.params).
• Check bypass: If params is absent or non-object, the bridge treats it as matching the current turn.
• Effect/sink: The bridge calls callGatewayTool("plugin.approval.request", ...) and returns an approval response to the app-server, potentially granting approvals to an unscoped request.

Vulnerable code:

function matchesCurrentTurn(requestParams: JsonObject | undefined, threadId: string, turnId: string): boolean {
  if (!requestParams) {
    return true;
  }
  ...
}

If the app-server (or a compromised/malicious binary launched via OPENCLAW_CODEX_APP_SERVER_BIN) can emit an approval request without thread/turn identifiers, it can still obtain approvals from the user/guardian for the current run, even though the request cannot be tied to a specific turn. This undermines the intended per-turn approval binding and may allow approval confusion or replay across turns within the same connection.

Recommendation

Require approval requests to be explicitly scoped to the current thread/turn, and reject requests that omit identifiers.

Example fix:

function matchesCurrentTurn(
  requestParams: JsonObject | undefined,
  threadId: string,
  turnId: string,
): boolean {
  if (!requestParams) return false;

  const requestThreadId =
    readString(requestParams, "threadId") ?? readString(requestParams, "conversationId");
  const requestTurnId = readString(requestParams, "turnId");

  ​// Require both identifiers to be present.
  if (!requestThreadId || !requestTurnId) return false;

  return requestThreadId === threadId && requestTurnId === turnId;
}

Additionally, consider logging/telemetry when rejecting unscoped approval requests so unexpected app-server behavior is visible.

Description

In runCodexAppServerAttempt, the Codex app-server is started with an approval policy that defaults to "never" and a sandbox mode chosen only from environment variables, not from the already-resolved OpenClaw sandbox context.

Impacts:

• Approval bypass / missing authorization: when approvalPolicy is "never", the app-server may execute privileged side-effect actions (e.g., commandExecution, fileChange) without ever emitting */requestApproval RPCs, so the OpenClaw approval bridge (handleCodexAppServerApprovalRequest) is never invoked.
• Sandbox policy mismatch / privilege escalation: OpenClaw resolves a sandbox context via resolveSandboxContext(...), but thread/start sends sandbox: resolveAppServerSandbox() sourced from OPENCLAW_CODEX_APP_SERVER_SANDBOX (default "workspace-write"). This can silently grant the app-server more filesystem/network access than the OpenClaw run’s sandbox intends (e.g., OpenClaw read-only, but app-server workspace-write; or danger-full-access if env set).

Vulnerable code (defaults):

function resolveAppServerApprovalPolicy(): "never" | "on-request" | "on-failure" | "untrusted" {
  const raw = process.env.OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY?.trim();
  if (raw === "on-request" || raw === "on-failure" || raw === "untrusted") {
    return raw;
  }
  return "never";
}

function resolveAppServerSandbox(): "read-only" | "workspace-write" | "danger-full-access" {
  const raw = process.env.OPENCLAW_CODEX_APP_SERVER_SANDBOX?.trim();
  if (raw === "read-only" || raw === "danger-full-access") {
    return raw;
  }
  return "workspace-write";
}

And the values are used when starting the app-server thread/turn:

• turn/start: approvalPolicy: resolveAppServerApprovalPolicy()
• thread/start: approvalPolicy: resolveAppServerApprovalPolicy() and sandbox: resolveAppServerSandbox()

Recommendation

Tie Codex app-server policy to the already-resolved OpenClaw sandbox/approval configuration and make secure behavior the default.

1. Default to an approval-requiring policy (e.g. "on-request" or "untrusted") unless explicitly configured otherwise.
2. Derive app-server sandbox mode from resolveSandboxContext(...), not only from environment variables, and never allow danger-full-access unless an explicit, trusted config enables it.

Example:

function resolveAppServerApprovalPolicy(params: EmbeddedRunAttemptParams) {
  ​// Prefer explicit OpenClaw config, and default to requiring approvals
  return (process.env.OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY as any) ?? "on-request";
}

function resolveAppServerSandboxFromContext(
  sandbox: Awaited<ReturnType<typeof resolveSandboxContext>>,
): "read-only" | "workspace-write" {
  if (!sandbox?.enabled) return "read-only";
  return sandbox.workspaceAccess === "rw" ? "workspace-write" : "read-only";
}

​// When starting:
​// approvalPolicy: resolveAppServerApprovalPolicy(params),
​// sandbox: resolveAppServerSandboxFromContext(sandbox),

Additionally, consider rejecting startup if env requests danger-full-access while OpenClaw sandbox is enabled/restricted, to prevent accidental privilege escalation.

Description

The plugin API now exposes api.registerAgentHarness(...), which lets any loaded plugin register an AgentHarness implementation. The harness is then considered during runtime selection and can be chosen (e.g., by returning supported: true with a high priority).

This is a high-privilege surface:

• A harness controls low-level agent execution (runAttempt, optional compact, reset).
• It can observe/modify prompts, tool calls, workspace/session file paths, and outputs.
• Registration is not gated to bundled/trusted plugins, nor is there a permission/allowlist check at registration time.

As a result, if third-party/untrusted plugins are allowed, a malicious plugin can register a harness that intercepts all agent runs and exfiltrates data or executes unintended actions.

Vulnerable code:

​// src/plugins/registry.ts
registerAgentHarness: (harness) => registerAgentHarness(record, harness),

and the registration implementation performs only ID uniqueness checks, then registers globally.

Recommendation

Gate agent harness registration to trusted/bundled plugins (or an explicit admin allowlist) and enforce it in code.

Options:

1. Manifest permission + enforcement

   • Add a manifest flag like capabilities: { agentHarness: true } (default false).
   • In registerAgentHarness, reject unless the plugin manifest grants it.

2. Bundled-only enforcement

   • Reject registerAgentHarness for plugins whose source/origin indicates non-bundled installation.

3. Config allowlist

   • Require config.plugins.allowAgentHarness: ["plugin-id"] and check it at registration.

Example (conceptual) enforcement in src/plugins/registry.ts:

const registerAgentHarness = (record: PluginRecord, harness: AgentHarness) => {
  if (!record.manifest?.capabilities?.agentHarness) {
    pushDiagnostic({
      level: "error",
      pluginId: record.id,
      source: record.source,
      message: "agent harness registration is not permitted for this plugin",
    });
    return;
  }
  ​// proceed with registration...
};

Also consider:

• Disallowing priority above a safe ceiling for non-core harnesses.
• Preventing supports() from claiming broad coverage unless explicitly configured.
• Logging and surfacing registered harnesses prominently to operators.

Description

runAgentHarnessAttemptWithFallback reruns the same attempt through the embedded PI harness when a selected (non-PI) harness throws in auto mode.

• A non-PI harness may have already executed side-effecting actions (e.g., sending messages via messaging tools, writing files, external actions) before throwing.
• The fallback logic does not check any "side effects already happened" indicator (e.g., replayMetadata.hadPotentialSideEffects, tool telemetry such as didSendViaMessagingTool, etc.) before rerunning.
• This can lead to duplicate/replayed actions (replay/TOCTOU-style bug) whenever the first harness partially succeeds then errors.

Vulnerable code:

try {
  return await harness.runAttempt(params);
} catch (error) {
  if (runtime !== "auto") {
    throw error;
  }
  log.warn(`${harness.label} failed; falling back to embedded PI backend`, { error });
  return createPiAgentHarness().runAttempt(params);
}

Recommendation

Gate fallback on an explicit replay safety signal, and default to no fallback when uncertain.

Options:

1. Require harnesses to throw a structured error that includes whether side effects may have occurred.
2. Or require harnesses to return an EmbeddedRunAttemptResult even on failure (with replayMetadata.hadPotentialSideEffects set) and only fallback if replayMetadata.replaySafe === true.
3. Or track side effects centrally (e.g., via shared tool telemetry/event bus) and block fallback once any side-effecting tool is invoked.

Example (conceptual) gating:

try {
  return await harness.runAttempt(params);
} catch (err) {
  if (runtime !== "auto") throw err;

  const replaySafe = isReplaySafeError(err); // must be false/unknown by default
  if (!replaySafe) {
    ​// avoid duplicate side effects
    throw err;
  }

  return createPiAgentHarness().runAttempt(params);
}

Description

The Codex app-server client logs the spawned process's stderr verbatim at debug level:

• Any secrets, tokens, or file contents that the codex process writes to stderr will be copied into OpenClaw logs.
• In practice, CLIs and SDKs may print API keys, auth headers, stack traces containing environment variables, or request payloads on failures.

Vulnerable code:

child.stderr.on("data", (chunk) => {
  const text = chunk.toString("utf8").trim();
  if (text) {
    embeddedAgentLog.debug(`codex app-server stderr: ${text}`);
  }
});

Whether this is exploitable depends on your logging configuration and who can access logs, but it is a common source of credential leakage in CI/hosted environments.

Recommendation

Avoid logging untrusted stderr verbatim, or ensure it is redacted and gated.

Options:

• Remove the log, or log only metadata (e.g., byte length / exit code).
• Redact known secret patterns before logging (API keys, bearer tokens, etc.).
• Gate behind an explicit dev-only flag and ensure production/CI default doesn’t emit it.

Example redaction:

function redact(s: string): string {
  return s
    .replace(/(Bearer\s+)[A-Za-z0-9._-]+/g, "$1<redacted>")
    .replace(/(OPENAI_API_KEY=)[^\s]+/g, "$1<redacted>");
}

child.stderr.on("data", (chunk) => {
  const text = chunk.toString("utf8").trim();
  if (text && process.env.OPENCLAW_DEBUG_CODEX_STDERR === "1") {
    embeddedAgentLog.debug(`codex app-server stderr: ${redact(text)}`);
  }
});

Description

writeCodexAppServerBinding() writes a JSON sidecar to a path derived directly from sessionFile using fs.writeFile(), and clearCodexAppServerBinding() deletes it with fs.unlink().

Even though sessionFile is generally expected to be under the sessions directory, these operations:

• are not atomic (can be partially written/corrupted if concurrent writers exist)
• follow symlinks by default

If an attacker (or untrusted local process) can create/replace ${sessionFile}.codex-app-server.json with a symlink/hardlink pointing to another file writable by the OpenClaw process, fs.writeFile() can overwrite that target.

Vulnerable code:

await fs.writeFile(
  resolveCodexAppServerBindingPath(sessionFile),
  `${JSON.stringify(payload, null, 2)}\n`,
);

Recommendation

Harden binding file writes/deletes against symlink attacks and corruption:

• Write atomically to a temp file in the same directory and rename() it into place
• Ensure the destination is a regular file (not a symlink) before replacing
• Optionally use open() with O_NOFOLLOW (where supported) / validate with lstat()
• Consider coordinating with the existing session write lock (same lock used for transcript updates)

Example (atomic replace with basic symlink check):

import path from "node:path";
import fs from "node:fs/promises";

const bindingPath = resolveCodexAppServerBindingPath(sessionFile);
const dir = path.dirname(bindingPath);
const tmpPath = path.join(dir, `.tmp-${path.basename(bindingPath)}-${process.pid}`);

​// Refuse to overwrite if an existing path is a symlink
try {
  const st = await fs.lstat(bindingPath);
  if (st.isSymbolicLink()) throw new Error("binding path is a symlink");
} catch (e: any) {
  if (e?.code !== "ENOENT") throw e;
}

await fs.writeFile(tmpPath, JSON.stringify(payload, null, 2) + "\n", { mode: 0o600 });
await fs.rename(tmpPath, bindingPath);

For deletion, similarly lstat() before unlinking, or remove only if it is a regular file you created.

Description

The new Codex provider plugin declares auth: [] (no user-configured credentials) but also returns a hard-coded synthetic token via resolveSyntheticAuth. Core discovery code uses synthetic auth to inject credentials into the embedded PI model registry, which can mark the provider as "available" even when the user is not actually logged in.

Impact:

• Misleading availability / auth bypass in selection logic: provider may appear usable because a credential entry exists.
• Unintended outbound requests & potential data exposure: because the provider catalog uses a remote base URL (https://chatgpt.com/backend-api) with auth: "token", downstream code paths may send requests (including user prompts or metadata) with Authorization: Bearer codex-app-server even when the user did not configure/consent to remote auth.

Vulnerable code:

resolveSyntheticAuth: () => ({
  apiKey: "codex-app-server",
  source: "codex-app-server",
  mode: "token",
}),

Related data-flow:

• Synthetic auth providers are enumerated (resolveRuntimeSyntheticAuthProviderRefs)
• Discovery injects returned apiKey into PI credentials (resolvePiCredentialsForDiscovery) which can cause providers to be treated as authenticated/available during model discovery/selection.

Recommendation

Do not return a usable-looking token unless it is derived from verified local Codex app-server/session state.

Options:

1. Gate synthetic auth behind a real session check (e.g., ask the Codex app-server whether the user is logged in), and return undefined when not authenticated.
2. If synthetic auth is only meant to unblock local harness operation, use a non-secret marker that cannot be mistaken for a real token and is not used to form outbound Authorization headers.

Example (gated):

resolveSyntheticAuth: async (ctx) => {
  const session = await codexAppServerGetSession();
  if (!session?.token) return undefined;
  return { apiKey: session.token, source: "codex-app-server", mode: "token" };
}

Also consider setting provider baseUrl to a local endpoint (if applicable) when using synthetic auth owned by the harness, or ensure request code refuses to send prompts when auth is synthetic/placeholder.

Description

mirrorCodexAppServerTranscript() acquires a session write lock and then calls readTranscriptIdempotencyKeys(), which reads the entire session transcript into memory and splits it into lines.

This can lead to denial of service if a transcript grows large (intentionally or naturally):

• fs.readFile(sessionFile, "utf8") loads the full file into memory
• raw.split(/\r?\n/) creates a large array of strings (high memory overhead)
• JSON.parse is attempted on every line
• This work happens while holding the session write lock, blocking other operations on that session for up to the lock timeout/hold duration

Vulnerable code:

raw = await fs.readFile(sessionFile, "utf8");
for (const line of raw.split(/\r?\n/)) {
  ... JSON.parse(line) ...
}

Recommendation

Avoid reading/parsing the full transcript under the write lock.

Mitigations:

1. Stream the file line-by-line with a hard cap (bytes/lines) and/or only scan a recent tail window.
2. Reduce lock contention by:
   • collecting idempotency keys outside the write lock (accepting minor races), or
   • storing idempotency keys in a separate small index file, or
   • using SessionManager/transcript format features that can query idempotency keys without full scan.

Example using streaming with a size cap (conceptual):

import { createReadStream } from "node:fs";
import readline from "node:readline";

async function readKeysCapped(file: string, maxLines = 50_000): Promise<Set<string>> {
  const keys = new Set<string>();
  const rl = readline.createInterface({ input: createReadStream(file, { encoding: "utf8" }) });
  let lines = 0;
  for await (const line of rl) {
    if (++lines > maxLines) break;
    ​// parse line and collect idempotencyKey
  }
  return keys;
}

Also consider bounding messages mirrored per call to prevent rapid transcript growth.

Description

createCodexDynamicToolBridge().handleToolCall() treats any resolved tool.execute(...) as success and returns success: true to the Codex app-server, without inspecting the returned AgentToolResult for failure indicators.

This is problematic because OpenClaw tool execution can return an error result without throwing. For example, src/agents/pi-tool-definition-adapter.ts catches tool exceptions and returns an AgentToolResult with details.status: "error" (instead of rethrowing) via buildToolExecutionErrorResult().

Impact:

• The Codex app-server may believe a tool call succeeded even when it failed, leading to inconsistent state.
• Safety/approval policies that rely on accurate failure reporting (e.g. approvalPolicy: "on-failure") may not trigger as intended, potentially bypassing intended interlocks.
• Side-effecting tools (messaging, cron, exec-like integrations) may be retried or followed up incorrectly because failures are masked as successes.

Vulnerable code:

const result = await tool.execute(call.callId, preparedArgs, params.signal);
...
return {
  contentItems: result.content.flatMap(convertToolContent),
  success: true,
};

Recommendation

Derive the response success from the returned AgentToolResult, not solely from whether execute() threw.

Suggested approach:

1. Define a small predicate that detects failure results (e.g. details.status === "error" or details.status === "failed", and/or other canonical fields used by your tools).
2. Set success accordingly.
3. Optionally, include a normalized error message in contentItems when the tool returned a failure result.

Example:

function isFailureResult(result: AgentToolResult<unknown>): boolean {
  const details = (result as { details?: unknown }).details;
  if (details && typeof details === "object" && !Array.isArray(details)) {
    const status = (details as Record<string, unknown>).status;
    return status === "error" || status === "failed";
  }
  return false;
}

const result = await tool.execute(call.callId, preparedArgs, params.signal);
const failed = isFailureResult(result);
return {
  contentItems: result.content.flatMap(convertToolContent),
  success: !failed,
};

Also consider updating telemetry (successfulCronAdds, messaging side-effects) to only record “success” when the tool result indicates success, not merely when no exception was thrown.

No security concerns identified. The Codex app-server binding files are session-scoped and path-validated. Sandbox and approval-policy resolution follow existing patterns. No secrets, credentials, or auth tokens are exposed through the new SDK surface.