Author

claudehowto

Remote Control failed to connect: Remote Control initialization failed が出るときに見えている症状

このエラーは、少なくとも issue 報告上では 2 つの場面で出ています。ひとつは macOS の Claude Code desktop app で /rc または /remote-control を実行した直後に即時表示されるケース、もうひとつは Linux の Code session で Remote Control を切り替えようとしたときに失敗するケースです。どちらも、ユーザー側の操作に対してすぐ失敗し、セッションが始まらない、または接続できないところが共通しています。

該当 issue は #57286 と #105233 です。前者では Claude Code 2.1.111、macOS、Max プランの報告があり、後者では Linux 上の Code セッションで同じ系統の失敗が起きると書かれています。

まず切り分けの軸は、これが「Remote Control 全体の不調」なのか、「Code セッションに限った不調」なのかです。issue #105233 では、Chat mode の Remote Control は問題なく同期する一方で、Code mode だけが失敗するとされています。つまり、同じ端末でもモード差で挙動が分かれる可能性があります。

issue #57286 側では、次のような状況が報告されています。Network connection to api.anthropic.com は正常、claude.ai 経由でのログイン状態も正常、VPN も使っていない。それでも /remote-control を実行するとすぐにエラーが出る、という流れです。モバイル側の Code tab にはセッションが出ない、ともあります。少なくともこの報告からは、単純なネットワーク断や認証切れだけでは説明できない症状だと読めます。

実際の報告文では、Linux 側での失敗はこう書かれています。

Running `/remote-control` returns: "Remote Control failed to connect: Remote Control initialization failed"

あわせて、デスクトップ側ではトグル操作自体が次のように失敗するとされています。

"Couldn't toggle Remote Control. Try again."

筆者の環境で確認できたのは OS と Python の実測値だけです。ここでは再現結果までは示せませんが、検証時点の環境は次の通りです。

[env_summary]
OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-10-27T08:56:25+09:00

この時点で言えるのは、少なくとも公開 issue ベースでは、同じエラー文字列が macOS と Linux の両方で報告されていることです。そして、コメント欄には「This bug still exists.」「bug still exists」「bug still exists ... on Win11」といった反応が繰り返し付いており、完全に解消したと断定できる状態ではありません。

手元で確認するなら、まずは「Chat mode ではなく Code mode だけで起きているか」を見てください。issue #105233 ではそこが重要な分岐でした。次に、/rc と /remote-control のどちらでも同じエラーになるかを確認します。#57286 では両方試しても同じ症状だったとあります。ここまで一致するなら、少なくともユーザー操作の違いではなく、Remote Control の初期化そのものが失敗している線が濃くなります。

現時点では、公開されている報告だけでは恒久的な解決策は確認できません。なので、この記事で言い切れるのは「同じ症状は既に複数環境で報告されている」「Chat mode と Code mode で差がある報告がある」「ネットワークやログイン状態が正常でも起こりうる」というところまでです。再現環境が近いなら、issue #57286 と #105233 の両方を見比べるのが早いです。

検証環境

OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-10-27T08:56:25+09:00

参照した Issue（anthropics/claude-code）: #57286, #105233

同じ著者の記事

`disabled after repeated failures · restart to retry` が出るときに見えていること

まず、この症状に当てはまるかどうかを先に切り分けます。今回の issue では、Remote Control が失敗を重ねたあとに無効化され、再起動しないと試し直せないように見える、という報告が 2 件あります。`[#78364](https://github.com/anthropics/claude-code/issues/78364)` では「3 回の一時的な失敗」で Remote Control が静かに恒久無効化される、と書かれています。`[#87269](https://github.com/anthropics/claude-code/issues/87269)` では、起動時に Remote Control の開始に失敗すると、そのセッション中は回復せず、再接続経路もないと報告されています。 今回の手元の確認では、Claude Code は Remote Control 機能自体を案内していますが、同時に複数インストールの存在も出ています。実際の出力は次のとおりです。 ```text $ claude --version 2.1.207 (Claude Code) ``

papoo.work

iTerm2 で file リンクを Cmd+click すると `The application can't be opened. -50` が出る

この症状は、Claude Code の出力に含まれるファイルリンクを iTerm2 で Cmd+click したときに、macOS のダイアログで `The application can't be opened. -50` が返ってくるものです。報告されている issue は [#76136](https://github.com/anthropics/claude-code/issues/76136) と [#78481](https://github.com/anthropics/claude-code/issues/78481) です。どちらも、リンク先の URI の形が原因だと説明されています。 読者側でまず見るべきなのは、クリックしたリンクが「ファイルパスっぽい文字列」ではなく、iTerm2 が OSC 8 のハイパーリンクとして解釈しているかどうかです。該当 issue では、Claude Code がファイルパスに対して scheme なしの URI を出してしまい、`NSWorkspace openURL:` に渡したところ Launch Services が

papoo.work

zsh で `command not found` や `dyld: Symbol not found` が出るときにまず見ること

手元にある issue には、少なくとも 2 つの別パターンがありました。ひとつは macOS 13.x で `claude` の起動そのものが落ちるケース、もうひとつは zsh の起動時に余計なエラーが毎回出るケースです。見た目は似ていますが、症状の場所が違います。 `[#69928](https://github.com/anthropics/claude-code/issues/69928)` では、インストール直後に次のような出力が出ています。 ```text Setting up Claude Code... dyld: Symbol not found: __ZTVNSt3__115basic_stringbufIcNS_11char_traitsIcEENS_9allocatorIcEEEE Referenced from: /Users/emmaborowski/.claude/downloads/claude-2.1.185-darwin-x64 (which was built for Mac OS X 13.0) Expected in: /usr/lib/lib

papoo.work

exit code 143 が出るときにまず疑うこと

`exit code 143` は、この材料だけを見ると「Claude Code のプロセスが SIGTERM で終わった」系の症状として扱うのが自然です。そう見てよさそうな根拠は、issue 側で実際に `SIGTERM (exit 143)` と書かれていることです。たとえば [#87658](https://github.com/anthropics/claude-code/issues/87658) では、Claude desktop アプリ内で 2 つ目の local Code セッションを始めると、先に動いていた CLI プロセスが SIGTERM で終了すると報告されています。 ただし、同じ `exit code 143` でも原因はひとつではありません。#76293 では、対話中の Claude Code が Bash tool の成功後に何のエラー表示もなく shell に戻り、あとでセッションを再開できたと書かれています。こちらの報告では、約 3 日動作していたこと、永続化された transcript が約 4.6 MB だったこと、request metadata

papoo.work

exit code 137 で Claude Code のプロセスが残り続けるときに見ること

まず、この症状に当てはまるかを切り分けます。 issue [#90889](https://github.com/anthropics/claude-code/issues/90889) では、macOS の Claude デスクトップアプリにバンドルされた Claude Code の headless 実行が、仕事自体は終えているのに `claude` プロセスだけが終了せず、放置すると OOM や swap 枯渇に進むと報告されています。コメントでは、残っているプロセスに対して `kill -TERM <pid>` を送るとおよそ 1 秒で正常終了したとも書かれています。つまり、少なくともその報告では「壊れて固まっている」というより、「自力で終わらないまま残留している」状態です。 報告の実例では、対象はデスクトップアプリの local-agent-mode サービスから起動される headless 実行でした。引数も `claude --output-format stream-json --input-format stream-json --permission-prompt-

papoo.work

Claude Code が exit code 134 で落ちるときに、まず見るべき差分

自分のケースかどうかを先に切り分けるなら、まず「Claude Desktop に付属している Claude Code だけが落ちるのか」を確認したほうが早いです。issue には、同じ macOS 12 系の機械で、Desktop app の bundled build だけが起動直後に死に、standalone CLI は動いた例がありました。つまり、少なくとも報告上は「macOS が古いから全部だめ」という話ではありません。 issue に出ているエラーは、どれも「起動直後に dyld がシンボルを見つけられず abort する」という形です。たとえば #91381 は `_DNSServiceGetAddrInfoEx`、#75206 は libc++ の symbol not found、#91550 も `_DNSServiceGetAddrInfoEx` でした。見た目は違っても、どれも `exit code 134` に落ち着いています。 #75206](https://github.com/anthropics/claude-code/issues/75206) では、

papoo.work

Couldn't link this session to a computer, so attached folder can't be used. が出るときに見ておくこと

この表示が出ると、クラウド側のセッションは立っているのに、ローカルのコンピュータへ結びつけられていません。結果として attached folder が使えません。少なくとも今回参照できた issue では、同じ文言の症状が2件報告されています。1件は Linux beta で local VM がそもそも起動せず、もう1件は VM 自体は起動しているのに device registration 側で止まっています。どちらも「リンクできない」という見た目は同じですが、壊れている場所は違います。 まず切り分けたいのは、あなたの環境がどちら寄りかです。 一方、[#97685](https://github.com/anthropics/claude-code/issues/97685) では、VM は起動して guest もつながるのに、Linux では cloud Cowork session が computer に bind できない、と報告されています。こちらは `hardwareKeyUnavailable: linux-not-yet-supported` という説明と、`de

papoo.work

`Error: Connection error.

at makeRequest (/$bunfs/root/sr` が出るときに見えているもの この症状は、Claude Code の CLI 内部で `makeRequest` から `Connection error` が投げられている状態として、少なくとも 2 件の issue で報告されています。該当するのは [#83872](https://github.com/anthropics/claude-code/issues/83872) と [#82703](https://github.com/anthropics/claude-code/issues/82703) です。どちらも報告されたエラー文字列は同じで、いま手元で確認できる範囲では、このエラー文そのものだけでは原因を一つに絞れません。 見えている issue の内容はかなり違います。#83872 は、cybersecurity 系の safeguard に触れたあとで `/rewind` を実行すると、繰り返し同じエラーに落ちるという報告でした。報告者は「cybersecurity pentest のレポート作成用の

papoo.work

`Permission for this action was denied by the Claude Code aut` と出るときに見分けたいこと

この症状は、少なくとも報告上は 2 つの別パターンがあります。ひとつは、auto mode の判定が本来通してよいツール呼び出しを止めるケース。もうひとつは、コンパクション後の文脈を「まだ有効なユーザー指示」とみなしてしまい、その後の呼び出しを拒むケースです。いずれも、ユーザー操作そのものが禁止されているというより、Claude Code 側の自動判定が原因になっています。 まず切り分けの軸は、拒否が「どの場面で」出たかです。長いセッションの途中で自動コンパクションが入った直後なら [#77158](https://github.com/anthropics/claude-code/issues/77158) の報告に近いです。ここでは、auto-mode の safety classifier がコンパクション時の割り込み文を恒久的な指示として扱い、次の正当な tool call を拒否したとされています。報告本文では、`--permission-mode auto` の環境、`claude-opus-4-8` と `claude-fable-5` の両方で再現したと書かれています。

papoo.work

MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of を見たときに確認したいこと

この症状でまず目に入るのは、Claude Code が大きなファイルを読み切れずに止まっている、という点です。issue では、`MaxFileReadTokenExceededError: File content (...) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content` という文言が繰り返し出ています。報告されているのは [#73486](https://github.com/anthropics/claude-code/issues/73486) と [#68927](https://github.com/anthropics/claude-code/issues/68927) です。 ```text MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maxim

papoo.work