openclaw - ✅(Solved) Fix ACP Codex auth regression: acpx wrapper forces isolated CODEX_HOME and breaks reuse of valid Codex OAuth [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73977Fetched 2026-04-30 06:30:11
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Timeline (top)
cross-referenced ×2closed ×1commented ×1

sessions_spawn(runtime="acp", agentId="codex") can fail authentication even when Codex CLI is already logged in and working on the same machine, because the OpenClaw ACPX wrapper forces CODEX_HOME to an isolated directory that does not contain the user's real Codex auth state.

In our case:

  • normal Codex CLI OAuth was valid in ~/.codex/auth.json
  • OpenClaw ACP/Codex failed as if authentication was missing
  • removing the forced CODEX_HOME override from the ACPX wrapper fixed the auth failure

This appears to be an OpenClaw integration bug rather than a Codex CLI bug.

Error Message

  1. emit a clear user-facing error explaining that ACP Codex is running with an isolated empty CODEX_HOME

Root Cause

sessions_spawn(runtime="acp", agentId="codex") can fail authentication even when Codex CLI is already logged in and working on the same machine, because the OpenClaw ACPX wrapper forces CODEX_HOME to an isolated directory that does not contain the user's real Codex auth state.

Fix Action

Fix / Workaround

  1. Install and authenticate Codex CLI normally so host auth works:
    • codex auth status shows OK
  2. Enable OpenClaw ACP with codex allowed.
  3. Spawn a Codex ACP session through OpenClaw:
    • sessions_spawn(runtime="acp", agentId="codex", mode="run", task="Reply with exactly: hello world")
  4. Observe auth failure / authentication-required behavior from the ACP path.
  5. Patch the OpenClaw ACPX wrapper to stop forcing isolated CODEX_HOME.
  6. Repeat the same ACP spawn.
  7. Observe that the auth failure disappears.

PR fix notes

PR #73943: fix(acpx): bridge Codex ACP auth

Description (problem / solution / changelog)

Summary

  • Problem: OpenClaw's Codex ACP wrapper forced an isolated Codex home that contained generated config only, so otherwise valid host Codex login state was not visible to Codex ACP sessions.
  • Why it matters: #73910 reports managed Codex ACP failing even though direct ACPX with the user's normal Codex auth works.
  • What changed: the isolated Codex home now bridges only an existing Codex auth.json; generated config.toml remains isolated, docs explain the behavior, and regression coverage locks in both the auth bridge and no-auth case.
  • What did NOT change (scope boundary): Codex config hooks, ACP timeout handling, permission profiles, adapter commands, and OpenClaw runtime policy are unchanged.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #73910
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: the Codex ACP wrapper always set CODEX_HOME to OpenClaw's generated isolated home, but that home only received generated config and never saw the host Codex auth.json that direct Codex ACP runs used.
  • Missing detection / guardrail: the existing regression test asserted config isolation but also asserted no source auth was bridged, so it locked in the broken managed-session behavior.
  • Contributing context: the timeout rejection part of the issue was already fixed on main; this keeps that behavior unchanged.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: extensions/acpx/src/codex-auth-bridge.test.ts
  • Scenario the test should lock in: source Codex auth.json is readable from the isolated Codex home, while source config.toml hooks are not imported and no OpenClaw ACP auth profile is synthesized.
  • Why this is the smallest reliable guardrail: the bug is in wrapper/home preparation before the external adapter starts.
  • Existing test that already covers this (if any): runtime.test.ts covers the unchanged Codex timeout ignore behavior.

User-visible / Behavior Changes

Codex ACP sessions can reuse existing host Codex login state when auth.json is present in the configured or default Codex home. The isolated Codex config.toml remains generated by OpenClaw.

Diagram (if applicable)

Before:
OpenClaw Codex ACP wrapper -> isolated codex-home with generated config only -> Codex ACP cannot see host auth

After:
OpenClaw Codex ACP wrapper -> isolated codex-home + bridged auth.json -> Codex ACP can use host login while config hooks stay isolated

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? Yes
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No
  • If any Yes, explain risk + mitigation: the wrapper exposes the existing Codex auth.json to the same Codex ACP adapter process that would read it in a direct host Codex ACP run. The bridge is limited to auth.json; Codex config hooks/callbacks are not imported, OpenClaw ACP auth profiles are not synthesized, and permission/runtime controls are unchanged.

Repro + Verification

Environment

  • OS: macOS local checkout
  • Runtime/container: Node 22 / pnpm workspace
  • Model/provider: Codex ACP wrapper path
  • Integration/channel (if any): ACPX bundled plugin
  • Relevant config (redacted): test fixture CODEX_HOME with synthetic auth.json

Steps

  1. Prepare a source Codex home with auth.json and a config.toml callback hook.
  2. Run prepareAcpxCodexAuthConfig.
  3. Inspect the generated isolated Codex home and wrapper.

Expected

  • The isolated Codex home can read auth.json.
  • Source config.toml hooks are not imported.
  • The generated wrapper does not bake in the source Codex home path.

Actual

  • Matches expected in the updated regression test.

Evidence

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios: focused ACPX auth bridge test, no-source-auth side effect, unchanged Codex timeout ignore behavior, and the Codex plugin test that was blocking the changed gate.
  • Edge cases checked: missing source auth leaves no generated auth, and source config hooks are not copied into the isolated home.
  • What you did not verify: live Codex ACP login against a real user account.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No
  • If yes, exact upgrade steps: N/A

Risks and Mitigations

  • Risk: exposing host Codex auth to the managed Codex ACP adapter could be broader than the previous generated-home isolation.
    • Mitigation: the adapter already consumes the same auth in direct Codex ACP runs; OpenClaw bridges only auth.json, keeps config hooks isolated, and leaves ACP permissions/runtime policy unchanged.

Tests run

  • git diff --check origin/main...HEAD
  • pnpm test extensions/acpx/src/codex-auth-bridge.test.ts extensions/acpx/src/runtime.test.ts extensions/codex/index.test.ts -- -t "bridges source Codex auth without importing config hooks|installs an isolated Codex ACP wrapper without synthesizing auth|ignores unsupported Codex ACP timeout config controls|registers with capture APIs that do not expose conversation binding hooks yet"
  • pnpm check:changed

Out of scope follow-ups

  • Live Codex ACP smoke with a real account.
  • Broader ACPX auth setup UX beyond the Codex auth.json bridge.
  • Any change to ACP timeout controls or Codex permission/runtime policy.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/tools/acp-agents.md (modified, +1/-1)
  • extensions/acpx/src/codex-auth-bridge.test.ts (modified, +54/-1)
  • extensions/acpx/src/codex-auth-bridge.ts (modified, +46/-1)
  • extensions/codex/index.test.ts (modified, +6/-6)
RAW_BUFFERClick to expand / collapse

ACP Codex auth regression: acpx wrapper forces isolated CODEX_HOME and breaks reuse of valid Codex OAuth

Summary

sessions_spawn(runtime="acp", agentId="codex") can fail authentication even when Codex CLI is already logged in and working on the same machine, because the OpenClaw ACPX wrapper forces CODEX_HOME to an isolated directory that does not contain the user's real Codex auth state.

In our case:

  • normal Codex CLI OAuth was valid in ~/.codex/auth.json
  • OpenClaw ACP/Codex failed as if authentication was missing
  • removing the forced CODEX_HOME override from the ACPX wrapper fixed the auth failure

This appears to be an OpenClaw integration bug rather than a Codex CLI bug.

Environment

  • OpenClaw: 2026.4.26
  • Platform: macOS
  • Node: 24.x
  • ACP backend: acpx
  • Codex ACP adapter: @zed-industries/codex-acp
  • Codex auth mode: OAuth / ChatGPT subscription

Expected behavior

If Codex CLI is already authenticated on the host, ACP-spawned Codex sessions should be able to reuse that working auth state, or OpenClaw should provide a documented and supported way to do so.

Actual behavior

OpenClaw launches Codex ACP through its wrapper with an isolated CODEX_HOME, so the child does not see the user's real ~/.codex/auth.json.

That causes ACP Codex runs to behave like they are unauthenticated even though direct Codex CLI is authenticated and working on the same machine.

Reproduction

  1. Install and authenticate Codex CLI normally so host auth works:
    • codex auth status shows OK
  2. Enable OpenClaw ACP with codex allowed.
  3. Spawn a Codex ACP session through OpenClaw:
    • sessions_spawn(runtime="acp", agentId="codex", mode="run", task="Reply with exactly: hello world")
  4. Observe auth failure / authentication-required behavior from the ACP path.
  5. Patch the OpenClaw ACPX wrapper to stop forcing isolated CODEX_HOME.
  6. Repeat the same ACP spawn.
  7. Observe that the auth failure disappears.

Root cause found locally

The installed OpenClaw ACPX runtime was forcing CODEX_HOME to an isolated OpenClaw-managed directory:

  • wrapper runtime:
    • dist/extensions/acpx/register.runtime-*.js
  • generated wrapper:
    • ~/.openclaw/acpx/codex-acp-wrapper.mjs

That isolated home had a generated config file but no real Codex OAuth state, while the actual working auth lived in:

  • ~/.codex/auth.json

After removing the forced CODEX_HOME override, ACP Codex got past the auth failure and executed successfully.

Why this is a bug

OpenClaw's openai-codex/* provider auth and Codex ACP adapter auth are separate systems, which is fine. But forcibly isolating CODEX_HOME without carrying forward valid Codex auth breaks a normal host setup where Codex CLI already works.

At minimum, OpenClaw should do one of:

  1. not override CODEX_HOME for Codex ACP by default
  2. copy/bridge the required Codex auth state into the isolated home
  3. provide an explicit supported config knob to control Codex ACP home/auth behavior
  4. emit a clear user-facing error explaining that ACP Codex is running with an isolated empty CODEX_HOME

Additional notes

  • This is separate from other ACP/Codex issues like stalled runs or workspace inference.
  • In our debugging session, fixing the CODEX_HOME override was the key step that changed Codex ACP from immediate auth failure to successful execution.

extent analysis

TL;DR

The most likely fix is to remove the forced CODEX_HOME override from the OpenClaw ACPX wrapper to allow Codex ACP sessions to reuse the valid Codex OAuth state.

Guidance

  • Identify the OpenClaw ACPX wrapper configuration and remove the forced CODEX_HOME override to prevent isolation of the Codex auth state.
  • Verify that the ~/.codex/auth.json file contains the valid Codex OAuth state and is accessible by the Codex ACP session.
  • Consider implementing one of the suggested solutions, such as copying or bridging the required Codex auth state into the isolated home, providing an explicit supported config knob, or emitting a clear user-facing error.
  • Test the Codex ACP session again after making the changes to ensure that the auth failure is resolved.

Example

No code snippet is provided as the issue is related to configuration and environment variables.

Notes

The fix may not apply to other ACP/Codex issues, such as stalled runs or workspace inference. The OpenClaw version 2026.4.26 and Node version 24.x may also impact the solution.

Recommendation

Apply the workaround by removing the forced CODEX_HOME override from the OpenClaw ACPX wrapper, as this is the most straightforward solution to resolve the auth failure issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If Codex CLI is already authenticated on the host, ACP-spawned Codex sessions should be able to reuse that working auth state, or OpenClaw should provide a documented and supported way to do so.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING