Rolling Claude Code Upgrades from a Running Session
The pkg upgrade doesn't kill your live session: Unix file semantics and a bectl snapshot are the whole story

When pkg upgrade replaces /usr/local/libexec/claude (or its cli.js equivalent), it doesn't overwrite the bytes of the currently open file. It writes a new file to a temp path and rename(2)'s it into place. The old inode is still referenced by every process that opened the file (and by the file descriptors those processes still hold), so its contents remain readable until the last reference goes away. The old inode is only reclaimed when both the directory link count and the open-fd count reach zero.

That's why lsof will show (deleted) for the file path of a running process whose binary was replaced. Nothing about that state harms the running process; the kernel keeps serving the old inode.

Concretely, on FreeBSD you can watch it:

# Before upgrade
ps auxww | grep -m1 "node.*claude"
# Note the PID.

sudo pkg upgrade -y claude-code
# The upgrade completes; the PID above is still running.

procstat -f <pid> | grep -i claude
# The file entry now says (deleted) but the fd is live.

Some binaries lazy-load parts of themselves: a shared library loaded on demand, a data file mmap'd late. If pkg swaps that file while the running process is between loads, the process crashes.

Claude Code is a Node app whose JavaScript is bundled and loaded at startup; by the time the claude command returns to its REPL loop it has already resolved everything it needs from disk into V8's heap. There is no lazy re-read of the binary. Same story for pretty much any Electron/Node CLI: single-load, then all runtime access is in-memory.

One thing that does get re-read per invocation: vendored helper binaries. On the pkg-installed FreeBSD build, Grep and Glob tool calls spawn a vendored ripgrep from vendor/ripgrep/x64-freebsd/rg, a path that doesn't exist in the port's layout. Those tools fail with ENOENT both before and after the upgrade; it's a packaging gap, not an upgrade regression, and the Bash tool with grep=/=find covers the same ground.

The upgrade also bumped linux_base-rl9, bash, and gettext-runtime. Same guarantee:

• linux_base-rl9 9.7 → 9.8: the Rocky userland files under /compat/linux/ are only read by Linux processes at exec(3) time. Any Linux process already running under the linuxulator holds its own loaded libc/loader pages. New Linux processes started after the upgrade see the new files. My host had no active linuxulator processes at upgrade time; the two Bastille jails on this box run their own linux_base-rl9 from their own pkg installs, so the host swap didn't touch them.
• bash 5.3.9 → 5.3.15: the shell binary I was using as my login shell continued to work. New shells picked up the new one.
• gettext-runtime: a shared library. Any process that already linked it holds its own resolved copy; new invocations link against the new .so. If you had a very long-lived C daemon that dlopens gettext on demand, this is the one to be cautious about. For interactive CLIs you're fine.

The pattern breaks for:

• Anything that dlopen s modules on demand from the upgraded path
• Long-running C daemons that reopen files at runtime and expect version invariants
• Kernel modules – those really do need a reboot to swap
• SUID/SGID binaries where the setuid bit re-check on exec matters
• Bundled resources loaded via readdir=/=fs.readFile at each tool invocation instead of at process start

None of these describe claude. The Node process is essentially a single read(2) of the bundled JavaScript at startup, and everything after is in-memory.

Auto mode in Claude Code routes every non-read-only tool call through a safety classifier before executing it. The classifier is itself a model call. Midway through drafting this post, the classifier's backend became temporarily unavailable, and every Write and Bash call in the old session was refused with:

claude-fable-5-1[1m] is temporarily unavailable, so auto mode cannot
determine the safety of Write right now.

Read-only tools kept working. The old (pre-upgrade) session had no way to recover from that except to wait. Killing it and relaunching on the freshly-installed 2.1.261 (the "I want to use the new version now" case) gave a session whose classifier path was healthy, and the write went through on the first try.