PR #75241: fix(openai): keep Codex attribution on provider transport

• Repository: openclaw/openclaw
• Author: bcdonadio
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/75241

Description (problem / solution / changelog)

Summary

• Problem: OpenAI-Codex hidden attribution currently reroutes Codex traffic through the generic OpenAI Responses SDK transport.
• Why it matters: The ChatGPT-backed Codex endpoint rejects that transport path with 401 We got your request, but your ChatGPT login did not make it to this service.
• What changed: Keep Codex traffic on the underlying provider transport while still applying the resolved OpenClaw attribution headers.
• What did NOT change (scope boundary): OpenAI/OpenAI-Codex attribution remains enabled; no provider auth/profile selection, model catalog, channel behavior, or public API contract changes.

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 #75240
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: createOpenAIAttributionHeadersWrapper treated openai-codex attribution by selecting createOpenAIResponsesTransportStreamFn() instead of the provider/underlying Codex stream function.
• Missing detection / guardrail: The wrapper test asserted that native Codex traffic was rerouted to the generic OpenAI transport instead of asserting that the working Codex provider transport is preserved while headers are added.
• Contributing context (if known): Header isolation showed the attribution headers were not the cause when sent through the existing Codex transport; the failing behavior followed the transport swap.

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: src/agents/pi-embedded-runner/openai-stream-wrappers.test.ts
• Scenario the test should lock in: openai-codex attribution adds the resolved OpenClaw headers but still invokes the provider transport supplied by the runner.
• Why this is the smallest reliable guardrail: It covers the exact wrapper branch that selected the wrong stream function without requiring a live ChatGPT auth profile.
• Existing test that already covers this (if any): src/agents/provider-attribution.test.ts and src/agents/openai-transport-stream.test.ts continue to cover header policy and OpenAI transport behavior.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

OpenAI-Codex requests with OpenClaw attribution should no longer fail authentication due to being routed through the generic OpenAI Responses SDK transport.

Diagram (if applicable)

Before:
openai-codex attribution -> generic OpenAI Responses SDK transport -> ChatGPT Codex 401

After:
openai-codex attribution -> existing Codex provider transport + OpenClaw headers -> successful Codex turn

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No new destination or capability; this preserves the existing OpenAI-Codex provider transport instead of switching to the generic OpenAI transport.
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Fedora Linux 43 (Cloud Edition), Linux 6.19.9-200.fc43.x86_64
• Runtime/container: Node 22 source checkout / systemd gateway
• Model/provider: openai-codex/gpt-5.4
• Integration/channel (if any): OpenAI-Codex provider path
• Relevant config (redacted): ChatGPT-backed auth profile with account id/token; secrets redacted

Steps

1. Run an OpenAI-Codex turn on a commit including d1b2d81752b8b613620affd5dec42461e178792b.
2. Confirm the attribution wrapper selects the generic OpenAI Responses SDK transport for openai-codex.
3. Observe the request fail with the 401 message from #75240.
4. Apply this PR and run the same OpenAI-Codex smoke path.

Expected

• OpenAI-Codex traffic keeps using the provider transport, includes OpenClaw attribution headers, and completes successfully.

Actual

• Before this PR, the generic SDK transport path returned 401 We got your request, but your ChatGPT login did not make it to this service.
• After this PR, the rebuilt local smoke returned OPENCLAW_AUTH_TEST_OK.

Evidence

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

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • pnpm test src/agents/provider-attribution.test.ts src/agents/openai-transport-stream.test.ts src/agents/pi-embedded-runner/openai-stream-wrappers.test.ts
  • pnpm build
  • Rebuilt local OpenAI-Codex smoke returned OPENCLAW_AUTH_TEST_OK with no 401.
• Edge cases checked:
  • Attribution headers originator, version, and User-Agent were sent through the existing Codex transport without causing the 401.
  • Generic OpenAI SDK transport still failed after attribution headers were removed, so the issue was not isolated to one bad attribution header.
• What you did not verify:
  • Full suite/Testbox was not run for this minimal draft PR.
  • A clean through-gateway model turn was not counted as proof because one CLI attempt fell back to embedded after the gateway WebSocket closed; gateway deep status was checked separately.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

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

Risks and Mitigations

• Risk: A future OpenAI-Codex path could require generic SDK-specific handling.
  • Mitigation: This PR preserves the previously working provider transport and adds a focused regression test for the attribution wrapper branch.

Changed files