まず自分のケースかどうかを切り分けるなら、親エージェントや対話画面に出る文言だけで判断しないほうがいいです。報告されている症状では、実際の upstream は認証失敗なのに、親側には [Request interrupted by user for tool use] とだけ見えることがあります。これは sub-agent を Agent tool で起動しているときに起きた例として #70958 に残っています。
この issue では、sub-agent が API 呼び出しで HTTP 401 を受けたとき、本来なら authentication_failed / 401 と分かるはずの失敗が、親 agent には「ユーザーが中断した」ように見えていました。報告文では、実際のエラーは sub-agent 側の transcript に残っていた一方、親側には診断に使える情報が渡らなかったとされています。つまり、見えているメッセージだけで「本当にユーザーキャンセルなのか」「トークン切れなのか」を区別できません。
似た挙動は interactive session でも報告されています。#74536 では、MCP tools が ToolSearch 経由で読み込まれたあと、次の API リクエストで 401 が返り、画面上は次のように出ました。
⏺ Please run /login · API Error: 401 Invalid authentication credentials
この報告では、セッション transcript に "error":"authentication_failed", "apiErrorStatus":401 が記録されていたと書かれています。さらに、MCP tools が読み込まれる前のリクエストは成功しており、失敗したのは「tools が読み込まれたあと、次のリクエスト」だけだったそうです。つまり、少なくともこのケースでは「最初からずっと認証できていない」のではなく、途中で 401 に落ちています。
手元で実際に取得できている一次情報は環境情報だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-06T08:51:45+09:00
このため、こちらでは再現手順や回避策を実測で裏取りできていません。少なくとも、今回の症状クラスタで確認できる事実は次の2点です。ひとつは、sub-agent 由来の 401 が親側ではユーザー中断に見えることがあること。もうひとつは、interactive session でも authentication_failed / 401 が発生し、画面表示と transcript の内容が一致しないことがあることです。
もし自分のケースを疑うなら、親側の文言だけで終わらせず、session transcript に authentication_failed や apiErrorStatus:401 が残っていないかを確認するのが先です。報告ベースでは、そこに本当の原因が出ています。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-06T08:51:45+09:00