Claude Desktop Linuxでセッションが消える、ARM64版の原因と復旧
Linux ARM64のClaude Desktopで、再起動するとセッションがサイドバーから消える不具合の整理です。EINVALの原因、会話データが残っている確認、復旧の考え方をまとめます。
Linux ARM64版のClaude Desktopで、再起動したらセッションがサイドバーから消えた場合、会話の中身はディスクに残っています。消えたのはサイドバーに並べるための一覧データだけで、claude --resumeで続きを開けます。原因は、アプリが一覧データを保存するときのディレクトリ検証が EINVAL で失敗し続けることだと、Issue #91433の報告者が突き止めています。
症状は「再起動で消える」だけで、動作中は何も起きない
報告されている症状は次のとおりです。
- セッションはアプリを起動している間は普通に動く
- アプリを終了して開き直すと、サイドバーから該当セッションが消える
- アーカイブ済みの絞り込みにも出てこない
- 画面にエラーは出ない
エラーが画面に出ないため、利用者の目には「履歴が突然なくなった」としか映りません。報告者の一人は、一晩かけた作業セッションをこの形で見失っています。
対象はDebian系のLinuxにdebパッケージで入れたARM64版です。Issueの報告は、Apple Silicon上のParallelsで動くUbuntu VMと、ベアメタルのAmpereサーバー(Ubuntu)の2環境から出ています。x86_64のLinuxやmacOS、Windowsでの報告は、このIssueにはありません。
原因はディレクトリを開く関数が返すEINVAL
Issueによると、アプリはセッション一覧を ~/.config/Claude/claude-code-sessions/<accountId>/<orgId>/local_<id>.json に保存します。保存の直前に保存先ディレクトリを開いて安全性を確かめる処理があり、そこで open() が失敗します。
main.log には、保存のたびに次の形のエラーが残ります。
[error] Failed to save session local_<id>: EINVAL: invalid argument,
open '/home/<user>/.config/Claude/claude-code-sessions/<accountId>/<orgId>'
{ errno: -22, code: 'EINVAL', syscall: 'open' }報告者の分析では、検証処理が O_RDONLY | O_DIRECTORY | O_NOFOLLOW を渡す際、フラグの数値がx86-64向けの値になっています。x86-64の O_DIRECTORY に当たるビット(8進で 0o200000)は、aarch64では O_DIRECT を意味します。ディレクトリを O_DIRECT 付きで開くと、カーネルは EINVAL を返します。
2人目の報告者が、ディレクトリを開くフラグの組み合わせを試した結果は次のとおりです。
| 開き方 | 結果 |
|---|---|
O_RDONLY | O_DIRECTORY(aarch64ネイティブ) | 結果成功 |
O_RDONLY | O_DIRECT | 結果EINVAL |
O_WRONLY | O_DIRECTORY | 結果EISDIR |
同じディレクトリへの mkdir と writeFile は成功します。ファイルシステムは壊れておらず、書けないのではなく、検証の open() だけが通らない状態です。
バンドルが実行環境の fs.constants を使わず、固定のx86-64値を持つ互換ライブラリ経由で定数を引いているのではないか、というのが報告者の推測です。これは推測であり、アプリ内部の実装がそうなっていると公式に確認された話ではありません。
自分の環境が該当するか確かめる
次の3つが揃えば、同じ不具合を疑えます。
dpkg --print-architecture
grep -c "Failed to save session" ~/.config/Claude/logs/main.log
grep -m1 "EINVAL" ~/.config/Claude/logs/main.log1行目が arm64 を返し、2行目が0でなく、3行目に open '.../claude-code-sessions/...' が出るなら該当です。ログの先頭付近に Loaded 1 persisted sessions のように、読み込めた件数が実際より少ないことを示す行が出る場合もあります。
根本のシステムコールの挙動は、aarch64のLinuxなら次の1行で再現できます。Issueに載っている最小の再現例です。
python3 -c "import os; os.open(os.path.expanduser('~'), os.O_RDONLY | 0o200000 | 0o400000)"OSError: [Errno 22] Invalid argument が出れば、aarch64のカーネルがx86-64のビット値を O_DIRECT と解釈していることの確認になります。これはカーネル側の挙動の確認で、Desktopの不具合そのものをこのコマンドが直接テストしているわけではありません。
会話データは消えていない
最初に確かめたいのは、会話のログが無事かどうかです。Issueでは、読み出しは影響を受けず、書き込みだけが失敗すると整理されています。Claude Code本体の会話記録は ~/.claude/projects/<プロジェクト>/<セッションID>.jsonl に保存され、Desktopの一覧データとは別の経路です。この保存場所とパスの決まり方は、Claude Codeのセッションエクスポートとトランスクリプトの保存場所にまとめてあります。
# 直近7日に更新された会話記録を新しい順に並べる
find ~/.claude/projects -name '*.jsonl' -mtime -7 -print0 \
| xargs -0 ls -lt | head -20消えたセッションの作業ディレクトリに対応するフォルダーに、最近の日時の .jsonl があれば、中身は残っています。ファイル名の拡張子を除いた部分がセッションIDです。
ターミナルからは、そのIDで会話を再開できます。
cd <作業していたディレクトリ>
claude --resume <セッションID>どのIDが消えたセッションのものか分からないときは、main.log の Mapping internal session local_X to CLI session Y という行が手がかりになります。Desktop側の内部IDとCLI側のセッションIDの組が、この行に記録されると2人目の報告者が述べています。
grep "Mapping internal session" ~/.config/Claude/logs/main.log | tail -20行の末尾の Y が、.jsonl のファイル名と一致するIDです。
Desktop側でも、プロンプト欄で /resume を入力すると、CLIで始めたセッションの一覧から選んで続きを開けます。ただし、一覧に出るのはCLIで始めたセッションです。サイドバーの一覧データが書けていないDesktop起点のセッションが、この一覧に出るかどうかは、Issueでは確認されていません。出なければ、上のCLIでの再開を使います。
サイドバーの一覧を取り戻すには
サイドバーの項目そのものを戻したい場合、Issueの報告者2人は次の方法を挙げています。
- Desktopを完全に終了する
~/.config/Claude/claude-code-sessions/<accountId>/<orgId>/に、local_<id>.jsonを手で書く- Desktopを開き直す
JSONに必要なのは、Desktop側のセッションID、cliSessionId、作業ディレクトリ、日時です。2人目の報告者は、このうち cliSessionId が肝心で、タイトルや作業ディレクトリや日時は会話記録から取り出せると書いています。最初の報告者は、手書きの項目を置いたら再起動後にセッションが再表示され、書き込み経路だけが壊れていると確認できたと報告しています。
キー名の綴りや日時の書式は、手元に残っている古い local_*.json を開いて同じ形に合わせるのが確実です。Issueの本文は項目の概要を述べるだけで、完全なスキーマを示していません。
ls -lt ~/.config/Claude/claude-code-sessions/*/*/ | head手書きした項目は、読み込み側が ensureStorageDir を通らないため、再起動後も残ると2人目の報告者は説明しています。ただし、これは非公式な回避策です。アプリの内部形式は変わりうるので、書く前に元のファイルのコピーを取り、会話記録の .jsonl には手を付けないでください。
Issue上では、第三者が会話記録と一覧データの対応を診断するスクリプトを紹介しています。公式のツールではありません。使う場合は、書き換えを伴う操作の前に、まず読み取り専用で結果を確認し、中身を自分の目で読んでからにしてください。
引き金はアプリの更新で、CLIの更新ではない
最初の報告者は、保存の失敗が始まった時刻が、Desktopに埋め込まれたClaude Codeランタイムが2.1.237から2.1.247へ更新された分と一致したため、CLIの更新が引き金だと書きました。
2人目の報告者が、これを訂正しています。この人の環境ではCLIの2.1.247への更新が完了しておらず、2.1.237のままなのに、保存は同じように壊れていました。ログを遡ると、アプリが1.34493.1から1.40609.0に切り替わった起動の6秒後に、最初のEINVALが出ています。つまり、失敗し始めたのはdebパッケージのclaude-desktop 1.40609.0からで、CLIの差分を調べても原因には行き着きません。
Linux版Desktopは自動更新されず、apt の通常の更新で新しい版が入ります。aptで更新した直後ではなく、次にアプリを起動した時点から不具合が始まる点にも注意が必要です。
修正を待つ間にできること
Issueはopenのままで、最後のコメントは2026年9月4日です。修正版のバージョン番号は書かれていません。報告者が挙げた修正案は、ビットの値を決め打ちせず実行時の fs.constants を使うこと、そして保存が繰り返し失敗したら利用者に警告することです。
その間にとれる手は、次のとおりです。
- 大事な作業は、セッションIDを控えるか、
~/.claude/projectsの会話記録をバックアップしておく。Desktopのサイドバーに頼らない - 再起動の前に、
main.logでFailed to save sessionが増えていないか見る。増えているなら、再起動でそのセッションがサイドバーから消える - 長い作業はCLIで進める。CLIは同じClaude Codeエンジンで、会話記録の保存はDesktopの一覧データとは別系統
sudo apt update && sudo apt upgradeで新しい版が出ていないか、ときどき確認する
公式のLinuxの案内には、DesktopがDebian系のUbuntu 22.04以降かDebian 12以降、x86_64またはarm64を対象としていて、ベータであることも書かれています。ベータの段階では、こうした環境依存の不具合が起きうる前提で使うことになります。FedoraやArchなど対象外の環境の扱いは、Claude DesktopはFedora・Archで使えるかで扱っています。
似た症状との切り分け
Linux版Desktopでは、症状が近い別件もあります。
| 症状 | 疑う先 |
|---|---|
| 再起動のたびにサインイン画面になる | 疑う先キーリングの保存失敗。Claude Desktop Linux版の再ログインが詳しい |
| 再起動後にセッションだけが一覧から消える(ARM64) | 疑う先本記事のEINVAL |
CLIが Aborted (core dumped) で落ちる | 疑う先glibcとARM64の組み合わせ。Claude CodeがLinux ARM64で繰り返しクラッシュする原因と切り分けが詳しい |
見分けるときは、main.log に Failed to save session とEINVALが並んでいるかを先に見ます。サインインは保たれているのにセッションだけが消えるなら、再ログインの話ではありません。
まとめ
ARM64のLinuxでClaude Desktopを再起動してセッションが消えたとき、失われているのはサイドバーの一覧データだけです。会話は ~/.claude/projects の .jsonl に残っているので、まずバックアップを取り、claude --resume <セッションID> で続きを開けます。サイドバーに戻したい場合は、local_<id>.json を手で書く回避策が報告されていますが、非公式です。修正が入るまでは、main.log の Failed to save session を、再起動前の合図として見ておくのが安全です。