lobster-biscuit

Bug: fresh codex/* agent sessions are pinned to PI despite embeddedHarness.runtime: "codex"

Summary

On OpenClaw 2026.4.23, an agent configured with model: codex/gpt-5.3-codex and embeddedHarness.runtime: "codex" works when an existing session entry is already pinned with agentHarnessId: "codex", but newly created explicit sessions are initialized/persisted with agentHarnessId: "pi" and then fail through the PI/openai-codex-responses path with:

Failed to extract accountId from token

This appears to contradict the Codex harness docs, which say codex/* models or explicit embeddedHarness.runtime: "codex" should select the Codex app-server harness.

Environment

• OpenClaw: 2026.4.23 (a979721)
• Install: npm/pnpm global install
• OS: Linux 6.8.0-107-generic x64
• Node: v24.14.0
• Gateway: systemd user service, loopback gateway on 127.0.0.1:18789
• Codex CLI auth: valid ChatGPT login, codex login status reports Logged in using ChatGPT
• Codex plugin: enabled and loaded
• Codex app-server config:

{
  "plugins": {
    "entries": {
      "codex": {
        "enabled": true,
        "config": {
          "appServer": {
            "transport": "stdio",
            "command": "/home/lermont-colizeum/.npm-global/bin/codex",
            "args": [
              "app-server",
              "-c",
              "sandbox_mode=\"danger-full-access\"",
              "--listen",
              "stdio://"
            ],
            "approvalPolicy": "never",
            "sandbox": "danger-full-access",
            "requestTimeoutMs": 120000,
            "mode": "yolo"
          }
        }
      }
    }
  }
}

Affected agent config:

{
  "id": "oc-engineer",
  "name": "oc-engineer",
  "workspace": "/home/lermont-colizeum/.openclaw/workspace-oc-engineer",
  "agentDir": "/home/lermont-colizeum/.openclaw/agents/oc-engineer/agent",
  "model": {
    "primary": "codex/gpt-5.3-codex",
    "fallbacks": []
  },
  "embeddedHarness": {
    "runtime": "codex",
    "fallback": "none"
  },
  "thinkingDefault": "high",
  "reasoningDefault": "off"
}

Steps To Reproduce

1. Configure a non-default agent with model.primary = "codex/gpt-5.3-codex" and:

"embeddedHarness": {
  "runtime": "codex",
  "fallback": "none"
}

1. Ensure the bundled codex plugin is enabled and loaded.

2. Ensure Codex CLI/app-server auth works:

codex login status
# Logged in using ChatGPT

1. Run a fresh explicit session via gateway-backed CLI:

openclaw agent \
  --agent oc-engineer \
  --session-id oc-engineer-fresh-prod-probe-20260425T103205Z \
  --message 'Fresh diagnostic probe. Reply exactly: OC_ENGINEER_FRESH_OK' \
  --thinking high \
  --timeout 180 \
  --json

Expected Behavior

Because the resolved model is codex/gpt-5.3-codex and the agent explicitly sets:

"embeddedHarness": {
  "runtime": "codex",
  "fallback": "none"
}

OpenClaw should select the Codex app-server harness, persist/run with:

agentHarnessId: codex
provider: codex
model: gpt-5.3-codex
runner: embedded
fallbackUsed: false

The turn should return the requested text.

Actual Behavior

Fresh explicit sessions are created/run with:

{
  "provider": "codex",
  "model": "gpt-5.3-codex",
  "agentHarnessId": "pi",
  "runner": "embedded",
  "fallbackUsed": false,
  "stopReason": "error",
  "payload": "Failed to extract accountId from token"
}

The session store then contains the new explicit session pinned to PI:

agent:oc-engineer:explicit:oc-engineer-fresh-prod-probe-20260425T103205Z
agentHarnessId: pi
model: gpt-5.3-codex

Control Test

If the existing session entry is repaired/pinned to:

"agentHarnessId": "codex"

then the same agent works correctly:

{
  "payload": "OC_ENGINEER_EXPLICIT_PIN_OK",
  "provider": "codex",
  "model": "gpt-5.3-codex",
  "agentHarnessId": "codex",
  "stopReason": "stop",
  "fallbackUsed": false,
  "runner": "embedded"
}

The canonical agent main session also works correctly when pinned:

{
  "payload": "OC_ENGINEER_MAIN_PIN_OK",
  "provider": "codex",
  "model": "gpt-5.3-codex",
  "agentHarnessId": "codex",
  "stopReason": "stop",
  "fallbackUsed": false,
  "runner": "embedded"
}

Investigation Notes

The Codex plugin is loaded and advertises:

{
  "providerIds": ["codex"],
  "agentHarnessIds": ["codex"],
  "description": "Codex app-server harness and Codex-managed GPT model catalog."
}

Local source inspection of dist/attempt-execution.runtime-D9l3hs12.js shows this effective pinning logic:

const sessionPinnedAgentHarnessId =
  params.sessionEntry?.sessionId === params.sessionId
    ? params.sessionEntry.agentHarnessId ?? (params.sessionHasHistory ? "pi" : void 0)
    : void 0;

That means once a fresh session entry has history but no explicit harness id, OpenClaw appears to pin it to PI before selectAgentHarnessDecision() can apply the per-agent embeddedHarness.runtime: "codex" policy.

The Codex harness itself only claims provider codex:

const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"]);

That part is correct for codex/gpt-5.3-codex; the failing path is the unexpected PI pin.

Workaround

State-repairing existing oc-engineer session entries from:

"agentHarnessId": "pi"

to:

"agentHarnessId": "codex"

restores those sessions, but it does not solve fresh session creation. A previous runtime hotfix that skipped provider stream registration for provider === "codex" masked the error, but that is not a production-safe fix and was removed.

Related Issues

• #57275: OAuth login fails with Failed to extract accountId from token in TUI (openai-codex)
• #55760: Embedded agent auth broken after pi-coding-agent bump / streamFn auth path
• #36604: Cron jobs fail with Failed to extract accountId from token when falling back to OpenAI Codex provider

This issue is narrower: codex/* with the Codex app-server harness is configured, but fresh explicit sessions are still pinned to PI.

Impact

Codex app-server harness deployments are not production-safe for fresh explicit/session-spawned agent work unless every new session entry is manually repaired or the caller reuses an already-pinned session.