Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix `/btw` uses plain OpenAI Responses with Codex OAuth instead of active Codex transport [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#80469•Fetched 2026-05-11 03:14:16
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Author
nimbleenigmanimbleenigma
Participants
clawsweeper[bot]clawsweeper[bot]nimbleenigmanimbleenigma
Timeline (top)
cross-referenced ×2commented ×1

/btw can fail in a Telegram chat with:

401 You have insufficient permissions for this operation.
Missing scopes: api.responses.write

This happens in a setup where the active/default model is canonical openai/gpt-5.5, but authentication is via a ChatGPT/Codex OAuth profile rather than an OpenAI API key.

Root Cause

Plain OpenAI Responses correctly rejects that token because it lacks api.responses.write. For Codex-backed OpenAI models, the side question should route through openai-codex / openai-codex-responses or a Codex-harness-native side completion instead.

Fix Action

Fixed

PR fix notes

PR #80493: Route Codex side questions through native side threads

Description (problem / solution / changelog)

OpenClaw already treats /side as an alias for /btw, but the implementation was still a generic one-shot provider call. That was fine for API-key providers, but it is the wrong transport once openai/gpt-5.5 is running through the Codex harness with a Codex OAuth profile: the side question falls through to plain OpenAI Responses auth, where the token can fail with missing api.responses.write scopes.

This change adds a small optional side-question hook to agent harnesses and implements it for the Codex app-server harness. When /btw or /side is routed to Codex, OpenClaw now forks the bound Codex thread as an ephemeral side thread, injects a side-conversation boundary, starts the side turn there, returns the answer as the existing chat.side_result payload, and unsubscribes afterward. The Codex path stays native for auth and thread context, but it preserves the existing /btw contract: the side turn is tool-free, read-only, and outside the parent transcript. PI and non-Codex providers keep the existing direct lightweight path.

If there is no Codex parent thread yet, OpenClaw now fails clearly and asks the user to send a normal message first instead of silently trying public OpenAI auth.

While touching the same routing area, this also makes OpenAI/Codex auth ordering less weird. New config can put Codex-compatible OAuth and API-key profiles under auth.order.openai, while existing openai-codex:* profiles and auth.order.openai-codex keep working. That gives users the obvious subscription-first, API-key-backup shape without forcing a migration.

Fixes #80469.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • docs/plugins/codex-harness.md (modified, +7/-6)
  • docs/providers/openai.md (modified, +39/-34)
  • docs/tools/btw.md (modified, +10/-4)
  • extensions/codex/harness.ts (modified, +4/-0)
  • extensions/codex/src/app-server/protocol-validators.ts (modified, +9/-0)
  • extensions/codex/src/app-server/protocol.ts (modified, +31/-0)
  • extensions/codex/src/app-server/side-question.test.ts (added, +364/-0)
  • extensions/codex/src/app-server/side-question.ts (added, +486/-0)
  • extensions/codex/src/app-server/thread-lifecycle.ts (modified, +3/-3)
  • src/agents/auth-profiles/order.test.ts (modified, +78/-0)
  • src/agents/auth-profiles/order.ts (modified, +16/-2)
  • src/agents/btw.test.ts (modified, +74/-0)
  • src/agents/btw.ts (modified, +44/-6)
  • src/agents/harness/types.ts (modified, +27/-0)
  • src/agents/pi-embedded-runner/run.overflow-compaction.test.ts (modified, +91/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +2/-1)
  • src/plugin-sdk/agent-harness-runtime.ts (modified, +2/-0)

Code Example

401 You have insufficient permissions for this operation.
Missing scopes: api.responses.write
RAW_BUFFERClick to expand / collapse

Summary

/btw can fail in a Telegram chat with:

401 You have insufficient permissions for this operation.
Missing scopes: api.responses.write

This happens in a setup where the active/default model is canonical openai/gpt-5.5, but authentication is via a ChatGPT/Codex OAuth profile rather than an OpenAI API key.

Environment / Context

  • Channel observed: Telegram DM command /btw ...
  • Default model: openai/gpt-5.5
  • Effective auth: openai-codex:<profile> OAuth
  • Normal agent runs in this environment use the Codex harness/runtime path successfully.
  • /btw is implemented as a lightweight side-question path separate from the normal run path.

Suspected Bug

/btw appears to bypass the normal selected harness/runtime auth transport and fall into a generic OpenAI Responses call.

That produces an invalid combination:

  • model/provider selection: openai/gpt-5.5
  • credential: Codex OAuth token
  • transport: plain OpenAI /v1/responses

Plain OpenAI Responses correctly rejects that token because it lacks api.responses.write. For Codex-backed OpenAI models, the side question should route through openai-codex / openai-codex-responses or a Codex-harness-native side completion instead.

Important Detail

This should not be fixed only via the PI helper path. The observed lane uses the Codex harness, so the invariant should be higher-level:

/btw must honor the active session's selected harness/auth transport, Codex included.

Expected Behavior

When the active/default model is openai/gpt-* and auth is backed by Codex OAuth, /btw should use the same effective transport/auth semantics as the active session. It should not call plain OpenAI /v1/responses with a Codex OAuth token.

Suggested Fix Shape

  • Make /btw resolve model/auth/runtime through the same plan as the active session.
  • Preserve /btw's no-tools/lightweight behavior, but do not bypass provider transport selection.
  • Add regression coverage for openai/gpt-5.5 + Codex OAuth + Codex harness, asserting /btw does not call plain OpenAI /v1/responses and instead uses the Codex transport or harness-native side completion.

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…
#api#configuration error#environment variable#network issue#logging issue

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 `/btw` uses plain OpenAI Responses with Codex OAuth instead of active Codex transport [1 pull requests, 1 comments, 2 participants]