Summary

/btw can still fail with a plain OpenAI Responses scope error in a Codex/ChatGPT OAuth setup, even on a build that includes the native Codex side-thread fix from #80493.

Observed user-visible error from a Telegram DM:

⚠️ /btw failed: 401 You have insufficient permissions for this operation. Missing scopes: api.responses.write. Check that you have the correct role in your organization (Reader, Writer, Owner) and project (Member, Owner), and if you're using a restricted API key, that it has the necessary scopes.

This looks like the old #80469 failure mode reappearing in an uncovered path: /btw appears to hit public OpenAI /v1/responses with a Codex OAuth token instead of routing through the active Codex app-server side-thread transport.

Environment

• OpenClaw version: 2026.5.28 (e932160)
• Channel: Telegram DM
• Auth profile: openai-codex:<email> OAuth / ChatGPT subscription, not an OpenAI API key
• Config shape includes:

{
  "auth": {
    "profiles": {
      "openai-codex:<email>": {
        "provider": "openai-codex",
        "mode": "oauth"
      }
    },
    "order": {
      "openai": ["openai-codex:<email>"]
    }
  },
  "agents": {
    "defaults": {
      "models": {
        "openai/gpt-5.5": {
          "agentRuntime": { "id": "codex" }
        }
      }
    }
  }
}

Repro

1. Use a Telegram DM backed by openai/gpt-5.5 through the Codex runtime and Codex OAuth.
2. Start a fresh session with /new.
3. Send a normal message and receive a normal assistant reply successfully.
4. Send a /btw ... side question.
5. /btw fails with the 401 api.responses.write missing scope error above.

In the observed case, the normal non-/btw turn immediately after /new worked fine via Codex OAuth. Only /btw failed.

Expected

For Codex-backed OpenAI models using ChatGPT/Codex OAuth, /btw should use the same effective Codex app-server/native side-thread auth path as the active session. It should not call public OpenAI Responses with the Codex OAuth token.

Actual

/btw reports the public OpenAI Responses missing-scope error, which strongly suggests it bypassed the native Codex side-thread path or fell back to the generic OpenAI provider path.

Related

• /btw uses plain OpenAI Responses with Codex OAuth instead of active Codex transport #80469 reported the original version of this issue.
• Use native Codex side threads and OpenAI auth fallback #80493 fixed it by adding native Codex side threads and OpenAI auth fallback.
• Fix Codex /btw parent thread lookup after compaction checkpoints #86393 may be related because it covers Codex /btw parent thread lookup after compaction checkpoints, though this report is specifically the api.responses.write fallback symptom.

Notes

The installed local build does contain dist/side-question-*.js with runCodexAppServerSideQuestion, so this is likely a regression, routing condition miss, or fallback path after /new rather than simply running an old pre-fix build.