[BUG] Claude stops with snapshot error

I've noticed the same thing. It seems to happen when you return to an old session. Restarting the session fixes it.

Interesting.

In my case there was a less than 30 minute, perhaps 5 minute (just guessing based on memory) delay between when the shell was working and when it stopped working. It was all within one prompt response from Claude. It was working when Claude first started responding and part way through the response its "shell" broke.

The .jsonl log I attached might confirm this? I don't know what all is included in those logs, or if there is a different one I should attach.

I'm experiencing the same issue. For me, it happens even in fresh sessions and is often so persistent that opening new sessions doesn't resolve it.

Details

I initially suspected it was due to working with multiple Claude Code sessions simultaneously (using git worktrees), but testing after killing all Claude processes showed this wasn't the cause. I also found stale processes in Activity Monitor after closing sessions, but killing them didn't help either.

Honestly, this happens more often than not for me.

The only reason I'm still using Claude Code is my recent Max plan subscription - Cursor seems more expensive currently, but that might change.

I also suspected it might be related to using ZSH with oh-my-zsh (saw someone mention this), but it occurs in bash too.

Actually, I didn't know how to switch to bash in my particular scenario.

Solution

I created a completely separate, streamlined environment specifically for Claude Code:

• Uses bash instead of zsh
• No Homebrew or mise contamination
• Only direct installations of required tools (Node.js, etc.)
• Force Claude Code to run through bash with export SHELL=/bin/bash

It's not ideal, but it works reliably, and I'll keep it this way until this gets resolved in Claude Code.

Also suffering this issue when claude code shells are left idle.

Feels good to know I'm not alone. If I restart the terminal window and Claude code, does it still have access to the prior session context?

You can use /resume command to continue one of the previous sessions.
There's even -c flag (claude -c) to resume the very last one.

It worked for a while, but since one of the latest updates (maybe 1.0.38), it doesn't work even with the fix (https://github.com/anthropics/claude-code/issues/2139#issuecomment-2994060105).

Sometimes it runs a command, but after a few commands, it stops working. Or sometimes doesn't work at all. Only restarting helps, but that's far from ideal for any longer work.

!Image

I can confirm I run into this error. It appears to only happen when CC is updated in the background, and your active session is using an old version.

I'm seeing this error too, but it seems to happen all the time (after a minute or two of coding) - not just when CC is updated in the background. I've tried to use bash as the shell (rather than zsh) and this doesn't seem to make any difference

Same for me. After a few minutes of usage, Claude Code becomes pretty much useless to me.
Can't wait for opencode to reach feature parity. I won't touch Claude Code. I'm even considering going back to Cursor at this point :/

I switched from Cursor to Claude Code 2-3 weeks ago, and in total, I've had it working for maybe 3 days in total. Everything else was a struggle. I'll try using Docker containers. If that doesn't work, bye bye Claude Code.

It took me a while to set Docker containers up, but even there, I have this issue.
It's crazy. I've tried 3 kinda completely different environments and I still get this issue. And I'm not the only one.
So I'm pretty sure now it's not PEBCAK.

Let me know if you need any additional info about my environment. Until then, I'll be using opencode.

This happens to me anytime I close the session and reopen it without restarting the entire terminal. Would nice to be able to manually clear those snapshot temp files or something. For reference, I use Kitty terminal

Guys, I think you need to hear this.

As someone who's been struggling with this for the past few weeks, this morning I switched to opencode and I have the same feeling of leveling up like I've had when I moved from Cursor's Chat to Claude Code.

<details>
<summary>Ramble</summary>
The reason I hesitated switching so much was that I have a pretty complex automated workflow.

It involves creating a new Cursor/VS Code workspace for every feature I work on, deals with memory files (plans, contexts...), and runs tests/code checks as part of the feedback loop.

So I asked opencode to convert my scripts. After like 15 minutes and just one small manual change, I can now switch from Claude Code to opencode and back easily. I don't even care what's driving the agent as long as it works.

Hopefully, one day, this bug in Claude Code gets fixed, and then I'll only care which model I'll be using, not the terminal tooling.

But if all goes well with opencode, I don't think I'll come back.
</details>

Anyway, try opencode. You'll thank me later.

Thanks Almir. I just heard about this: https://github.com/NomenAK/SuperClaude - seems to sit on top of Claude code - maybe through this you may not have the same issues...

As of v1.0.48 we moved the shell snapshot to ~/.claude/shell-snapshots
This should make it easier to inspect and even edit the shell snapshot.
It should also prevent the OS from cleaning up the snapshot while you're using it.
Can you please test and let us know how it goes?

Doesn't show up anymore.
Thanks!

still shows up for me even after repeated restarts

@shallow-alchemy can you post the new error message?

Yeah. I just noticed its slightly different now

<img width="949" height="158" alt="Image" src="https://github.com/user-attachments/assets/e3d6b3b9-f964-40f6-9b37-c3bc87e5413c" />

Want me to open a new issue? (to be clear, the missing error seems resolved)

interesting, can you please post the relevant line from that file? here's fine

line 4415:
export PATH='^[[31m^[[1mUsage Error^[[22m^[[39m: The 'yarn global' commands have been removed in 2.x - consider using 'yarn dlx' or a third-party plugin instead

ok @shallow-alchemy you probably have something like this in your path, which is broken in yarn 2.x export PATH="$(yarn global bin):$PATH"

I can fix it so bad PATH values don't break the shell snapshot though

Received this over and over. Have encountered this numerous times in the last week.

  ⎿  Error: zsh:source:1: no such file or directory:
     /var/folders/np/07tz0kxd2_s29kwyllf4jwnm0000gn/T/claude-shell-snapshot-57bf

Only fix is to terminate the process and then resume the conversation from a new instance. Would really be lovely if this would stop happening so frequently though.

This fixed after 1.0.52. Can you please update and let me know if you are still having problems?

This fixed after 1.0.52. Can you please update and let me know if you are still having problems?

Yes, I am on 1.0.52 and have encountered this error about a dozen times today.

It is possible, depending on when 1.0.52 released, that I still had active instances on the previous version. I can verify that prior to working today I had 1.0.52 but not all instances were restarted when I began work. I'll update if I hit this on a session that I know I've restarted today.

1.0.52 writes snapshot files in $CLAUDE_CODE_CONFIG_DIR/shell-snapshots

1.0.52 writes snapshot files in $CLAUDE_CODE_CONFIG_DIR/shell-snapshots

For now I'm assuming that 1.0.52 released, auto-updated, and borked all of my existing ~~conversations~~ sessions, in which case, no big deal plus a one-time issue.

I will report back if I continue to see this behavior in new sessions. Thanks for your efforts.

Ubuntu user here. It worked for me when I switched from Gnome Console to Gnome Terminal, not sure why.

I am also using Claude Code in the native installation.

For me, it seems to only be triggered by launching another claude code session (2 running at once) and crashes claude code entirely.

For me, it seems to only be triggered by launching another claude code session (2 running at once) and crashes claude code entirely.

You are correct, that causes it. Switching terminal didn't help.

Also, I would like to add that this happens to me using version 1.0.53.

This issue is worse for me in 1.0.53.

Can confirm that this started happening to me in 1.0.53 pretty often. @wolffiex Can you consider re-opening this issue?

I downgraded to 1.0.52 and continue to had issues. I then downgraded again
to 1.0.51 and have been using it without issues.

On Wed, Jul 16, 2025 at 2:12 PM Germano Eichenberg @.***>
wrote:

germanoeich left a comment (anthropics/claude-code#2139) <https://github.com/anthropics/claude-code/issues/2139#issuecomment-3079732993> Can confirm that this started happening to me in 1.0.53 pretty often. @wolffiex <https://github.com/wolffiex> Can you consider re-opening this issue? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/2139#issuecomment-3079732993>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC3LC3HA4HKDRRNGUYNQQ33I2IX5AVCNFSM6AAAAAB7MUYMZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZZG4ZTEOJZGM> . You are receiving this because you commented.Message ID: @.***>

Downgrading to 1.0.51 worked for me as well. Don't forget to disable auto-update when doing this!

Thanks ! 1.0.51 works for me too ! I didnt use claude for a week and started having this issue today... running 1.0.56.

FYI: Disable autoupdate: claude config set -g autoUpdates disabled

This should not be marked as closed @wolffiex :)

EDIT: Well, it worked for 5 minutes and then:

● Bash(ls -la)
  ⎿  Error: /bin/bash: line 1: /home/user/.claude/shell-snapshots/snapshot-bash-1753059559185-swhw51.sh: No such file or directory

Which make claude code unusable. In two vscode window, one worked 6 hours ago for ~4 hours and then started bugging, while that happened I opened another instance of vscode for another folder and the problem got even worst. Pretty much all command it tries to run fails.

@Extarys can you please paste the error? Can you run with -d and paste the output?

@wolffiex Hmm, my bad - this will need investigating on my side.
I think I found the culprit: claude-swarm. I didn't realise it happens only while using it. I'll keep my eyes open today and report back here if I notice the same behaviour with claude directly.

https://github.com/parruda/claude-swarm/issues/93

Yes, finally :)

● Now I'll run the Rust type checker using cargo check in the src-tauri directory,
  which is the standard way to typecheck Rust code:
[DEBUG] executePreToolHooks called for tool: Bash
[DEBUG] Executing hooks for PreToolUse:Bash
[DEBUG] Getting matching hook commands for PreToolUse with query: Bash
[DEBUG] Found 0 hook matchers in settings
[DEBUG] Matched 0 unique hooks for query "Bash" (0 before deduplication)
[DEBUG] Found 0 hook commands to execute
[DEBUG] Getting matching hook commands for Notification with query: undefined
[DEBUG] Found 0 hook matchers in settings
[DEBUG] Matched 0 unique hooks for query "no match query" (0 before deduplication)
[DEBUG] Bash tool invoked with command: cd src-tauri && cargo check
[DEBUG] Bash tool description: Run Rust type checker on all source files
[DEBUG] AutoUpdaterWrapper: Installation type: npm-local, using native: false

● Bash(cd src-tauri && cargo check)
  ⎿  Error: /bin/bash: line 1: 
     /home/user/.claude/shell-snapshots/snapshot-bash-1753148921648-xe43fp.sh: No 
     such file or directory
[DEBUG] Stream started - received first chunk

● Let me try a different approach:
[DEBUG] executePreToolHooks called for tool: Bash
[DEBUG] Executing hooks for PreToolUse:Bash
[DEBUG] Getting matching hook commands for PreToolUse with query: Bash
[DEBUG] Found 0 hook matchers in settings
[DEBUG] Matched 0 unique hooks for query "Bash" (0 before deduplication)
[DEBUG] Found 0 hook commands to execute
[DEBUG] Writing to temp file: /run/media/user/project/.claude/settings.local.json.tmp.3357173.1753181211124
[DEBUG] Preserving file permissions: 100644
[DEBUG] Temp file written successfully, size: 224 bytes
[DEBUG] Applied original permissions to temp file
[DEBUG] Renaming /run/media/user/project/.claude/settings.local.json.tmp.3357173.1753181211124 to /run/media/user/project/.claude/settings.local.json
[DEBUG] File /run/media/user/project/.claude/settings.local.json written atomically
[DEBUG] Bash tool invoked with command: cd /run/media/user/project/src-tauri && cargo check
[DEBUG] Bash tool description: Run Rust type checker on all source files
[DEBUG] AutoUpdaterWrapper: Installation type: npm-local, using native: false

● Bash(cd /run/media/user/project/sr
      c-tauri && cargo check)
  ⎿  Error: /bin/bash: line 1: 
     /home/user/.claude/shell-snapshots/snapshot-bash-1753148921648-xe43fp.sh: No 
     such file or directory
[DEBUG] Stream started - received first chunk

● Let me check the current directory and run cargo check directly:
[DEBUG] executePreToolHooks called for tool: Bash
[DEBUG] Executing hooks for PreToolUse:Bash
[DEBUG] Getting matching hook commands for PreToolUse with query: Bash
[DEBUG] Found 0 hook matchers in settings
[DEBUG] Matched 0 unique hooks for query "Bash" (0 before deduplication)
[DEBUG] Found 0 hook commands to execute
[DEBUG] Writing to temp file: /run/media/user/project/.claude/settings.local.json.tmp.3357173.1753181218204
[DEBUG] Preserving file permissions: 100644
[DEBUG] Temp file written successfully, size: 244 bytes
[DEBUG] Applied original permissions to temp file
[DEBUG] Renaming /run/media/user/project/.claude/settings.local.json.tmp.3357173.1753181218204 to /run/media/user/project/.claude/settings.local.json
[DEBUG] File /run/media/user/project/.claude/settings.local.json written atomically
[DEBUG] Bash tool invoked with command: pwd && ls -la
[DEBUG] Bash tool description: Check current directory and list files
[DEBUG] AutoUpdaterWrapper: Installation type: npm-local, using native: false

● Bash(pwd && ls -la)
  ⎿  Error: /bin/bash: line 1: 
     /home/user/.claude/shell-snapshots/snapshot-bash-1753148921648-xe43fp.sh: No 
     such file or directory

Any traction on this? It is a constant (bigger than a) paper cut for me and others.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.