openclaw - ✅(Solved) Fix BUG: OpenClaw-managed Codex ACP uses isolated CODEX_HOME without auth bridge and sends unsupported timeout config [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#73910Fetched 2026-04-29 06:13:21
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
cross-referenced ×2labeled ×2commented ×1

OpenClaw-managed Codex ACP sessions fail even though direct ACPX to Codex succeeds. The managed path prepares an isolated Codex home without Codex auth, and after auth is bridged locally it still sends an unsupported timeout config option that Codex ACP rejects.

Root Cause

OpenClaw-managed Codex ACP initially fails because the isolated Codex home has no authentication. After adding a local auth bridge, the managed session advances but fails before the prompt with: Agent rejected session/set_config_option for "timeout"="120": Invalid params (ACP -32602).

Fix Action

Fixed

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)

Code Example

Direct ACPX with normal Codex home succeeds.
Direct ACPX with isolated Codex home lacking auth fails with: Authentication required.
Direct ACPX with isolated Codex home plus only auth.json bridge succeeds.
OpenClaw-managed Codex ACP then fails with: Agent rejected session/set_config_option for "timeout"="120": Invalid params (ACP -32602).
Removing the user-configured timeout value does not stop timeout=120 from being sent because the ACPX plugin schema applies timeoutSeconds: 120 as a default.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

OpenClaw-managed Codex ACP sessions fail even though direct ACPX to Codex succeeds. The managed path prepares an isolated Codex home without Codex auth, and after auth is bridged locally it still sends an unsupported timeout config option that Codex ACP rejects.

Steps to reproduce

  1. Use OpenClaw 2026.4.26 with ACP enabled and Codex available as an ACP agent.
  2. Verify direct ACPX to Codex can complete a trivial prompt using the normal Codex home.
  3. Run direct ACPX with an isolated CODEX_HOME that contains only an OpenClaw-style generated config file; observe that Codex reports Authentication required.
  4. Add only a local auth.json bridge/symlink into that isolated Codex home and rerun direct ACPX; observe that Codex succeeds.
  5. Run an OpenClaw-managed ACP Codex session with a trivial prompt.

Expected behavior

OpenClaw-managed Codex ACP should either reuse/bridge existing Codex authentication safely or provide a documented setup flow for the isolated Codex home, then run the prompt without sending unsupported generic config options.

Actual behavior

OpenClaw-managed Codex ACP initially fails because the isolated Codex home has no authentication. After adding a local auth bridge, the managed session advances but fails before the prompt with: Agent rejected session/set_config_option for "timeout"="120": Invalid params (ACP -32602).

OpenClaw version

2026.4.26 (be8c246)

Operating system

Ubuntu 26.04 LTS

Install method

npm global install

Model

Codex ACP default / OpenClaw-managed ACP Codex agent

Provider / routing chain

OpenClaw managed ACP runtime -> ACPX -> Codex ACP adapter

Additional provider/model setup details

Direct ACPX to Codex works on the same machine and authentication. The failure appears specific to OpenClaw-managed ACP session preparation/config handoff.

Logs, screenshots, and evidence

Direct ACPX with normal Codex home succeeds.
Direct ACPX with isolated Codex home lacking auth fails with: Authentication required.
Direct ACPX with isolated Codex home plus only auth.json bridge succeeds.
OpenClaw-managed Codex ACP then fails with: Agent rejected session/set_config_option for "timeout"="120": Invalid params (ACP -32602).
Removing the user-configured timeout value does not stop timeout=120 from being sent because the ACPX plugin schema applies timeoutSeconds: 120 as a default.

Impact and severity

OpenClaw-managed Codex ACP is unusable in this setup even though direct ACPX and Codex authentication are healthy. This blocks using Codex through OpenClaw ACP sessions.

Additional information

This may be the same compatibility class as unsupported generic ACP config options being sent to other ACP adapters, but Codex also has a separate isolated-auth-home issue.

extent analysis

TL;DR

Remove the unsupported "timeout" config option to fix the OpenClaw-managed Codex ACP session failure.

Guidance

  • Identify and remove any default or user-configured timeout values in the OpenClaw-managed ACP session setup.
  • Verify that the ACPX plugin schema is not applying a default timeout value, such as timeoutSeconds: 120.
  • Check the OpenClaw documentation for a documented setup flow for isolated Codex homes and authentication bridging.
  • Test the OpenClaw-managed Codex ACP session with a trivial prompt after removing the timeout config option.

Notes

The issue appears to be specific to the OpenClaw-managed ACP session preparation and config handoff, and may be related to a broader compatibility issue with unsupported generic ACP config options.

Recommendation

Apply workaround: Remove the unsupported "timeout" config option, as this is a specific and targeted fix for the reported 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

OpenClaw-managed Codex ACP should either reuse/bridge existing Codex authentication safely or provide a documented setup flow for the isolated Codex home, then run the prompt without sending unsupported generic config options.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix BUG: OpenClaw-managed Codex ACP uses isolated CODEX_HOME without auth bridge and sends unsupported timeout config [1 pull requests, 1 comments, 2 participants]