Some claude sessions cant be resumed with "No tmux session running" error after restarting iterm2

[JonasBaeumer]

Hi,

I am repeatedly running into issues of trying to restart some of my sessions after I restarted my iTerm2. Some session can be easily resumed some other sessions give me a consistend No tmux session running error even after many restart attempts (R). What is strange to me that some other session can be resumed while some session can not (across different projects). Has anyone had this error before? Do you have any ideas on how to fix that?

So far I have experienced this in the following session types:

1. Claude code
2. Terminal

It seems like forking the session is not possible since that seems to somehow also dependant on tmux (at least in the UI).

[asheshgoplani]

Hey @jonas — sorry for the long turnaround.

Now that several stability fixes have landed (v1.7.39, 1.7.40, 1.7.43), a few diagnostics would help me distinguish a real macOS tmux lifecycle bug from a config issue:

1. agent-deck --version — v1.7.43 is current
2. Before iTerm2 restart: agent-deck -p <profile> list --json | jq -r '.[] | "\(.status) \(.id) \(.title)"'
3. After iTerm2 restart: same command. Which specific session IDs flip to error?
4. The exact stderr text when you attempt agent-deck session start on a failed one?
5. tmux ls output before and after the iTerm2 restart

On fork: agent-deck session fork branches the conversation from the same JSONL content — it does NOT recover the dead tmux scope. For a recoverable session, agent-deck session start <id> is correct.

Some macOS tmux servers die when their originating terminal closes (no systemd linger equivalent on macOS). If that's your case, the fix is to spawn agent-deck sessions from a detached tmux server, which ties into issue #687 (socket isolation). Share those diagnostics and we'll figure out whether you're hitting the macOS lifecycle issue or something new.