authentication failed という表示だけでは原因は絞れませんが、今回の issue 群で確認できるのは、少なくとも 2 つの別系統があることです。ひとつはリモート制御のセッション作成で 401 が返るケース、もうひとつは Windows 上での操作中に別の経路から制御が抜けるケースです。後者は別の症状ですが、同じく認証や制御の前提が崩れているときに起きています。
まず、自分の症状がどちらに近いかを切り分けたほうが早いです。/remote-control を開いた瞬間に「Session creation failed — see debug log.」となるなら、#78580 の系統です。そこでは code-session 作成エンドポイントが 401 を返し、claude auth logout と claude auth login をやり直しても失敗し続けたと報告されています。issue の本文では「stale/incorrect cached subscription tier」が疑われていますが、これは報告者の推測であって、こちらで裏が取れているわけではありません。
報告の中で実際に確認されているのは、--debug-file で見たときに、code-session の作成が 3 回リトライされ、毎回 hard 401 で落ちていたことです。ログそのものは提示されていないので、ここで言えるのはそこまでです。
一方、#86667 は authentication failed そのものではなく、Windows 11 の C:\Windows\System32 から操作していた遠隔セッションで、C:\$GetCurrent の削除がまず system-path guard に止められたあと、cmd /c rd /s /q ... に包んだ経路では止められず、その後の destructive command が timeout 後もバックグラウンドで続いてしまった、という報告です。これは認証失敗とは違いますが、「表面上は止まったのに、別の経路で実行が続く」タイプの事故としては重要です。少なくとも、Windows での遠隔操作では、単純なコマンド名だけで安全性を判断できないことが読み取れます。
今回、手元で実際に取得できた出力は環境情報だけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-20T08:51:34+09:00
このため、こちらでは authentication failed の再現確認も、--debug-file の中身の確認もできていません。言えるのは、報告済みの 2 件を見る限り、同じ文字列や同じ画面に見えても原因は分かれているということです。/remote-control 直後の 401 なのか、Windows 上での制御逸脱なのかで、見る場所は変わります。
もし手元で同じ症状を追うなら、まずは authentication failed が出る操作直後の状況をそのまま残し、debug log を確認できるならそこを先に見たほうがよさそうです。少なくとも #78580 の報告では、そのログが原因特定の出発点になっていました。現時点では、恒久的な解決策が確立したとは言えません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-20T08:51:34+09:00