/ Claude Code v2.1.118

Fixed potential data loss when writing files across filesystem boundaries — atomic writes now handle EXDEV and EPERM errors gracefully (search for "EXDEV")
Fixed session reattachment cleanup — CLAUDE_BRIDGE_REATTACH_SESSION and CLAUDE_BRIDGE_REATTACH_SEQ environment variables are now properly cleared on TUI restart to prevent stale reattachment (search for "CLAUDE_BRIDGE_REATTACH_SESSION")
Improved credentials lock handling with proper retry logic and error reporting: "Could not acquire credentials lock at ... after N retries" (search for "credentials lock")
Fixed potential memory leak in fullscreen renderer where character pools were unnecessarily reset every 5 minutes

The build it came inv2.1.118

22 Apr 2026 · 34 entries, this one is #31.

Either side of it

Open the release →

Names in this entry

envCLAUDE_BRIDGE_REATTACH_SESSION
One resolver now decides whether Remote Control starts and in which mode, weighing flags, settings and env vars.
envCLAUDE_BRIDGE_REATTACH_SEQ
Part of the Remote Control reattach handoff Claude Code puts in a child process's environment when it relaunches or respawns a session that had a bridge session. Holds the last message sequence number of the bridge session named by CLAUDE_BRIDGE_REATTACH_SESSION, as a decimal integer, and is only written when greater than 0. The new process parses it as the sequence number to reattach at, only when CLAUDE_BRIDGE_REATTACH_SESSION is set, and removes it from the environment after reading.

Is this right?