Summary

• Problem: models status --probe can report false auth/format failures for OpenAI Codex OAuth profiles even when the selected profile is valid.
• Why it matters: the probe path is the operator-facing way to confirm whether a profile needs re-auth; false failures can send users into unnecessary login loops.
• What changed: run auth probes through the PI harness in raw model-run mode, forward resolved profile credentials through the embedded agent API-key seam, keep Codex Responses on the boundary-aware transport even when a session custom stream exists, and provide required fallback instructions for native Codex Responses requests.
• What did NOT change (scope boundary): no auth storage format changes, no profile-order changes, no external CLI credential discovery changes, and no new provider/network surface.

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

• Related fix: CLI auth status/probe path regression #75223
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: the auth probe path used a non-raw embedded run shape that could retain session/custom transport behavior and did not reliably expose the resolved auth profile credential through the PI agent API-key seam.
• Missing detection / guardrail: existing tests covered status/probe mapping and default boundary-aware fallbacks, but not the selected-profile probe call shape or Codex Responses with custom session streams.
• Contributing context (if known): native ChatGPT Codex Responses requests require a non-empty instructions field, and probes can have an intentionally empty system prompt.

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/commands/models/list.probe.test.ts, src/agents/pi-embedded-runner/stream-resolution.test.ts, src/agents/openai-transport-stream.test.ts
• Scenario the test should lock in: selected-profile OpenAI Codex probes use the PI harness and raw model-run mode, Codex Responses keeps the boundary-aware stream over custom session streams, and native Codex Responses probes always send required instructions.
• Why this is the smallest reliable guardrail: it exercises the call-shape and transport seams without a live provider dependency.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

openclaw models status --probe --probe-provider openai-codex --probe-profile <profile> should be less likely to return false auth/format failures for valid OpenAI Codex OAuth profiles.

Diagram (if applicable)

Before:
models status --probe -> embedded run with session/custom transport -> missing or malformed Codex request -> false probe failure

After:
models status --probe -> PI raw model run -> resolved profile credential + boundary-aware Codex transport -> accurate probe result

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) Yes
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: resolved credentials are forwarded only to the matching run provider via the existing API-key seam; no credential material is logged or exposed in tests.

Repro + Verification

Environment

• OS: Linux / WSL2
• Runtime/container: Node 24, pnpm workspace
• Model/provider: openai-codex/gpt-5.5
• Integration/channel (if any): CLI auth probe
• Relevant config (redacted): user-scoped auth profile store with an OpenAI Codex OAuth profile

Steps

1. Configure an OpenAI Codex OAuth profile.
2. Run openclaw models status --agent graphiti-agent --probe --probe-provider openai-codex --probe-profile openai-codex:soylei --probe-timeout 90000 --probe-max-tokens 16 --json.
3. Inspect the probe result.

Expected

• A valid profile reports status: ok.

Actual

• Before this fix, the same valid profile could report auth/format failure because the probe run did not consistently reach the Codex Responses transport with the resolved profile credential and native-compatible payload shape.

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: targeted unit/seam tests for Codex transport params, stream-resolution routing, and probe run call shape.
• Edge cases checked: native ChatGPT Codex backend vs custom Codex-compatible proxy behavior; custom session stream preservation for non-Codex providers.
• What you did not verify: live provider probe on this exact upstream-main worktree, because local user config contains downstream-only keys rejected by upstream main; the same fix was live-verified on the downstream runtime before extracting this minimal upstream patch.

Commands run:

• pnpm docs:list
• pnpm install
• pnpm exec oxfmt --check --threads=1 src/agents/openai-transport-stream.ts src/agents/openai-transport-stream.test.ts src/agents/pi-embedded-runner/run/attempt.ts src/agents/pi-embedded-runner/stream-resolution.ts src/agents/pi-embedded-runner/stream-resolution.test.ts src/commands/models/list.probe.ts src/commands/models/list.probe.test.ts
• pnpm test src/agents/openai-transport-stream.test.ts src/agents/pi-embedded-runner/stream-resolution.test.ts src/commands/models/list.probe.test.ts
• pnpm check:changed --staged

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/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: forcing Codex Responses over a custom session stream could surprise a caller that expected a generic custom stream for Codex.
  • Mitigation: the override is limited to openai-codex-responses, which needs provider-specific credential/payload handling; non-Codex custom session streams keep existing behavior.