Author

claudehowto

ENOTDIR が出るときに見るべき 2 つの壊れ方

まず、この ENOTDIR は 1 つの症状に見えて、少なくとも issue 上では 2 つの壊れ方が報告されています。どちらも「ディレクトリとして扱うはずの場所が、そう扱えない」という点は共通ですが、起きる場所が違います。

ひとつは、デスクトップアプリでセッションを fork するときです。~/.claude/projects/<project> がシンボリックリンクになっている環境で、LocalSessions.forkSession の IPC ハンドラが ENOTDIR を投げ、UI 側でエラーが飲み込まれてしまう、という報告でした。結果として何も起きないか、親履歴のない空の新規セッションになるようです。これは #90931 に書かれています。

もうひとつは Bash tool 側です。こちらはコマンドが走る前に落ちます。issue では、セッションディレクトリを /proc/self/fd/N/ 経由で作ろうとして ENOTDIR になっている、と報告されています。Linux で procfs がない、あるいは不完全な環境で再現し、mkdirat(fd, name, mode) に置き換えるべきだという提案が出ています。これは #93680 です。

筆者環境の実測出力は、今回の本文中には症状の再現ログがないため、環境情報だけを載せます。

[env_summary]
OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-09-12T08:51:48+09:00

この2件を比べると、切り分けの入口はかなりはっきりしています。デスクトップアプリで「fork したのに反応がない」「空のセッションになる」なら #90931 の系統がまず疑わしいです。逆に Bash tool の実行そのものが毎回即死して ENOTDIR を見るなら #93680 に近いです。

現時点で、少なくとも issue から確認できる範囲では、どちらも根本修正がこの本文だけでは確定していません。#90931 は closed ですが、本文からは回避策までは読み取れませんでした。#93680 は open で、報告者は mkdirat への変更を求めています。ここでは断定せず、再現条件に近いかどうかを先に見たほうがよさそうです。

検証環境

OS          : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python      : 3.8.13
検証日時    : 2026-09-12T08:51:48+09:00

参照した Issue（anthropics/claude-code）: #93680, #90931

同じ著者の記事

Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified と [Unsupported Image] が同時に出るときに見る場所

まず切り分けたいのは、この症状が Claude Desktop 全体の不調なのか、それとも Desktop 内の Code tab だけで起きているのか、です。今回の issue [#93696](https://github.com/anthropics/claude-code/issues/93696) と [#93693](https://github.com/anthropics/claude-code/issues/93693) では、どちらも「Claude Desktop on Windows」で画像を送ると `[Unsupported Image]` になり、さらに workspace の起動に `Failed to start Claude's workspace - RPC error -1: SDK version 2.1.260 not verified` が出る、と報告されています。 ここで重要なのは、コメントでこの workspace エラーが「Claude Desktop 固有ではなく、Claude Desktop アプリ内で動く Claude Code の

papoo.work

`OAuth session expired and could not be refreshed` が出るときにまず確認したいこと

この症状は、少なくとも issue [#81937](https://github.com/anthropics/claude-code/issues/81937) と [#93521](https://github.com/anthropics/claude-code/issues/93521) で報告されています。どちらも「OAuth のセッションが期限切れで、更新できない」という同じ文言に見えますが、出方が少し違います。 ```text Failed to authenticate: OAuth session expired and could not be refreshed ``` ```text Failed to authenticate. API Error: 401 {"type":"error","error":{"type":"authentication_error","message":"OAuth access token has been revoked."},"request_id":null} ``` 一方 [#93521](https://gith

papoo.work

Claude Desktop で HTTP 503 が出るときに見えていたこと

まず切り分けたいのは、「起動時や設定画面の読み込みで 503 が返っている」のか、それとも「一度サインインできたあと、裏側の認証や設定取得だけが失敗している」のかです。今回の issue では、その両方に近い報告がありました。 一方で [#93577](https://github.com/anthropics/claude-code/issues/93577) は、`app://localhost/setup-desktop-3p` を開くと常に「Unable to load configuration」になり、ログには次のように出ています。 ```text ``` この issue では、Claude-3p の profile cache は消しても改善せず、アプリは最新バージョンで、OAuth 側の `invalid_grant / session_stale_relogin` はフルログアウトと再ログインで解消済みでした。それでも 503 は残っています。コメントでは「Claude Code の issue には見えないので、必要なら新規 issue を」と案内されており、少な

papoo.work

`ERR_INVALID_ARG_TYPE` が出て Chrome / Brave の native host が落ちるときの切り分け

最初に見ておきたいのは、これが Windows 系の issue に寄っているかどうかです。今回の報告はどちらも Windows 11 上で、Claude Code の Chrome 連携まわりの native host が起動直後に `ERR_INVALID_ARG_TYPE` で落ちる、という形でした。ひとつは [#57846](https://github.com/anthropics/claude-code/issues/57846)、もうひとつは [#76556](https://github.com/anthropics/claude-code/issues/76556) です。 この症状に当たっているかは、かなりはっきりしています。Claude Code の Chrome 連携を使った瞬間に、拡張機能が「接続されていない」扱いになる。あるいは native host 自体がすぐ死んで、`ERR_INVALID_ARG_TYPE` が見える。どちらも issue 側では Windows 上の再現例でした。少なくとも、今回集められた報告からは macOS や Linux での

papoo.work

`Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出るときに見る場所

この症状に当てはまるかどうかは、まず「どの画面で止まるか」でかなり絞れます。今回の issue では、Cowork の workspace 起動時にだけ `Failed to start Claude's workspace — Download failed. Check your internet connection and try again.` が出ています。通常の Chat は動いていて、workspace の開始だけ失敗する、という切り分けでした。macOS 側の報告ではダウンロードバーが 1〜2% で止まったあと失敗し、Windows 側の報告では UI 上はネットワーク失敗に見えるものの、ログでは VM バンドルの取得・展開・検証までは通っています。 つまり、このエラー文そのものをそのまま「回線不良」と受け取ると外す可能性があります。少なくとも報告されている 2 件では、見た目の文言と実際の原因が一致していませんでした。 macOS 側の issue は [#64234](https://github.com/anthropics/claude-code/issues

papoo.work

`respawn pane failed: fork failed: Device not configured` が出るときに見るところ

この症状は、Claude Code の Agent Teams と tmux の組み合わせで、teammate の spawn が失敗したときに報告されています。代表例は [#77559](https://github.com/anthropics/claude-code/issues/77559) です。報告文では、`Failed to send command to pane %2: respawn pane failed: fork failed: Device not configured` という形で失敗しており、別の pane `%3` でも同じエラーが出ています。Issue 本文では、`ENXIO / "Device not configured"` は「harness が tty を失った pane を指している」ことを示唆すると書かれています。 まず自分のケースかどうかを見分けるなら、次の2点が合っているかを確認するとよさそうです。ひとつは、Agent Teams の tmux セッションで teammate の spawn 時にだけ落ちること。もうひとつは、エラーメ

papoo.work

Error: CreateSession 400: {"error":{"message":"GitHub repository access check failed — re-authorize GitHub in settings" で止まる /ultrareview の見分け方と、手元で確認できたこと

この症状は、`/ultrareview` 実行時に `CreateSession 400` で落ち、本文に `github_repo_access_denied` と `re-authorize GitHub in settings` が入っているものです。報告としては [#56000](https://github.com/anthropics/claude-code/issues/56000) と [#65708](https://github.com/anthropics/claude-code/issues/65708) が同じ文字列を含んでいました。 まず切り分けたいのは、`gh auth status` が通るかどうかではありません。issue 側では、`gh auth` が有効でも、Claude 側の GitHub 認証チェックで失敗しています。[#56000](https://github.com/anthropics/claude-code/issues/56000) の報告には、`gh auth status` はログイン済み、トークンの scope もあり、`gi

papoo.work

authentication expired と出るのに、gh は正しくログインしているように見えるとき

まず、この表示が自分のケースかを切り分けます。Issue [#67087](https://github.com/anthropics/claude-code/issues/67087) では、Claude Desktop が > GitHub CLI authentication expired. Run `gh auth login` to refresh pull request status. というバナーを繰り返し出していた一方で、同じセッション内で `gh auth status`、`gh api user`、`gh pr status` が成功していました。コメントでは、`main.log` にその日の `gh/auth` 関連の `[error]` がなく、`LocalSessions.getPrChecks` のポーリングも失敗していない、と報告されています。つまり、少なくともこの issue では「本当に期限切れの認証情報が壊れている」という単純な話ではありませんでした。 もう一つの issue [#84214](https://github.com/anthrop

papoo.work

TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync を見たら、まずこの2件の issue と突き合わせる

このエラーに当たった場合、少なくとも今回渡された issue 報告では、症状の軸がかなりはっきりしています。 `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` で、`keys` と `messages` の件数がずれている状態です。該当する報告は [#88052](https://github.com/anthropics/claude-code/issues/88052) と [#87872](https://github.com/anthropics/claude-code/issues/87872) の2件でした。どちらも open で、解決済みの報告はありません。 まず、自分のケースかどうかを見るなら、次の3点です。 エラー文に `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が入っている `keys=... messages=...` のように、両者の数が1件ずれている スタックト

papoo.work

`Failed to start Claude's workspace — VM service not running.` が出たときに、まず疑うべきこと

このエラーは、少なくとも今回読んだ issue 群では Windows 側の仮想化まわりと強く結びついています。 ただし、根っこは 1 つではなさそうです。報告を追うと、同じ文言でも原因が違うケースが混ざっています。 最初に切り分けたいのは、自分の症状がどちら寄りかです。 つまり、この系統では「Windows の仮想マシン機能が無効」「必要な機能が入っていない」側をまず疑うのが自然です。 一方で [#82688](https://github.com/anthropics/claude-code/issues/82688) では、原因がもっと単純で、`CoworkVMService` が `Stopped` になっていただけだったケースが報告されています。 この報告では、`Start-Service CoworkVMService` を通常権限で実行するとすぐ直った、とされています。アプリ側が再起動や再インストールを勧めるより先に、サービス自体を起動すべきだ、という指摘です。 この 2 件だけでも、エラー表示が同じでも対処は同じではないと分かります。 「Windows の機能が

papoo.work