openclaw - 💡(How to fix) Fix [Bug]: native codex harness uses broken isolated CODEX_HOME (harness-auth) while ~/.codex works [1 comments, 2 participants]

Summary

When using the native Codex harness (codex/gpt-5.4 with embeddedHarness.runtime: "codex"), OpenClaw launches Codex app-server with an isolated CODEX_HOME under:

~/.openclaw/agents/main/agent/harness-auth/codex/<hash>

On my machine, that generated home is the failing layer.

• Real Codex auth under ~/.codex works.
• The generated harness-auth Codex home does not.
• Native codex/* turns then fail with 401 Unauthorized: Missing bearer or basic authentication in header.

A local workaround is to override plugins.entries.codex.config.appServer.command with a wrapper that forces Codex app-server to use the real working ~/.codex instead of the generated bridge home.

Environment

• OpenClaw: 2026.4.21 (f788c88)
• Codex CLI: 0.123.0
• macOS (Apple Silicon)
• Auth method: ChatGPT / Codex OAuth
• Model: codex/gpt-5.4
• Harness config:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "codex/gpt-5.4",
        "fallbacks": ["openai-codex/gpt-5.3-codex-spark"]
      },
      "embeddedHarness": {
        "runtime": "codex",
        "fallback": "none"
      }
    }
  },
  "plugins": {
    "entries": {
      "codex": {
        "enabled": true
      }
    }
  }
}

Why this appears to be a harness-auth bridge bug

The official docs for the Codex harness say:

• Codex auth must be available to the app-server process
• Use the same auth material your local Codex app-server uses

Docs:

• https://docs.openclaw.ai/plugins/codex-harness

However, the installed OpenClaw Codex harness appears to generate and inject its own isolated Codex home instead of using the already-working local one.

From the installed bundle on my machine:

• dist/extensions/codex/harness-*.js calls prepareCodexAuthBridge({ bridgeDir: "harness-auth", ... })
• then injects env.CODEX_HOME = bridge.codexHome

I can reproduce that the generated home is broken while the real home is healthy.

Reproduction

1. Ensure native Codex CLI auth is working normally.

HOME=/Users/<user> CODEX_HOME=/Users/<user>/.codex codex login status

Result:

Logged in using ChatGPT

1. Find the generated harness-auth Codex homes.

find ~/.openclaw/agents/main/agent/harness-auth/codex -mindepth 1 -maxdepth 1 -type d | sort

Example generated dirs on my machine:

/Users/<user>/.openclaw/agents/main/agent/harness-auth/codex/06bfb5171eff0241
/Users/<user>/.openclaw/agents/main/agent/harness-auth/codex/a9df8fee07a27f2d

1. Point Codex CLI at the latest generated harness-auth home.

ACTIVE_HOME=$(find ~/.openclaw/agents/main/agent/harness-auth/codex -mindepth 1 -maxdepth 1 -type d | sort | tail -n 1)
HOME=~ CODEX_HOME="$ACTIVE_HOME" codex login status

Actual result:

Error checking login status: missing field `id_token` at line 6 column 3

1. Trigger a native Codex harness turn (for example /new in Discord, or any run with codex/gpt-5.4).

Actual result in gateway log:

unexpected status 401 Unauthorized: Missing bearer or basic authentication in header

I also saw:

codex app-server thread resume failed; starting a new thread

and then the turn failed before reply.

Additional evidence

The generated bridge homes do contain copied Codex-looking files such as:

• auth.json
• config.toml
• installation_id
• sqlite state/log files

So this does not look like a simple “file missing” problem. It looks more like OpenClaw is generating/syncing an auth home that Codex app-server / Codex CLI cannot reliably use.

Workaround

This local workaround appears necessary on my machine:

#!/bin/zsh
export HOME="/Users/<user>"
export CODEX_HOME="/Users/<user>/.codex"
exec /opt/homebrew/bin/codex "$@"

Configured as:

{
  "plugins": {
    "entries": {
      "codex": {
        "enabled": true,
        "config": {
          "appServer": {
            "command": "/Users/<user>/.openclaw/bin/codex-home-wrapper"
          }
        }
      }
    }
  }
}

This is not ideal, because it bypasses the harness-auth bridge entirely and relies on the user discovering and wiring a wrapper manually.

Expected behavior

One of these should be true:

1. The generated harness-auth Codex home should be fully usable by Codex CLI / Codex app-server.
2. Or the native harness should provide an official config path to reuse the same local Codex auth material (~/.codex) without requiring a wrapper workaround.
3. Or OpenClaw should detect that the generated bridge home is invalid and fail with a much more specific error than a downstream 401.

Important distinction

This is not just “my OAuth token is bad.”

On the same machine:

• real ~/.codex works immediately
• the generated harness-auth home fails immediately

So the breakage appears to be in the OpenClaw Codex auth-home bridge layer, not in the underlying local Codex login.