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.
Summary
/btwcan fail in a Telegram chat with: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
/btw ...openai/gpt-5.5openai-codex:<profile>OAuth/btwis implemented as a lightweight side-question path separate from the normal run path.Suspected Bug
/btwappears to bypass the normal selected harness/runtime auth transport and fall into a generic OpenAI Responses call.That produces an invalid combination:
openai/gpt-5.5/v1/responsesPlain OpenAI Responses correctly rejects that token because it lacks
api.responses.write. For Codex-backed OpenAI models, the side question should route throughopenai-codex/openai-codex-responsesor 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:
/btwmust 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,/btwshould use the same effective transport/auth semantics as the active session. It should not call plain OpenAI/v1/responseswith a Codex OAuth token.Suggested Fix Shape
/btwresolve model/auth/runtime through the same plan as the active session./btw's no-tools/lightweight behavior, but do not bypass provider transport selection.openai/gpt-5.5+ Codex OAuth + Codex harness, asserting/btwdoes not call plain OpenAI/v1/responsesand instead uses the Codex transport or harness-native side completion.