Macos on Lessons learned

Backing up ~/.claude and ~/.codex without archiving your AI logins

Sat, 31 Oct 2026 22:29:00 +0100

If you back up the whole ~/.claude or ~/.codex folder, the restore works, and the backup now holds everything an infostealer wants. The same folder holds your settings, every session transcript in plaintext, and, on Linux, the login itself:

~/.claude/.credentials.json # Claude Code login, mode 0600
~/.codex/auth.json # Codex login when file storage is in use
~/.claude/projects/*/*.jsonl # transcripts: prompts, tool output, file contents

Split the folder into two lists. Back up what you wrote: settings, instructions, skills, hooks, and memory. Keep transcripts as optional encrypted data. Leave login files out of routine backups and log in again after a restore.

Where AI client state lives on macOS and Linux

I checked these paths against Claude Code 2.1.316, Claude Desktop for Linux 4.4212.0, ChatGPT for macOS 1.2026.183, the Codex desktop app for macOS 26.1027.30824, and Codex source at commit 67f0994. “Documented” means the vendor docs name the path. “Observed” means I found it by inspecting the official build so that it can change in any release.

Client	State root	Login material	Evidence
Claude Code	`~/.claude/` and `~/.claude.json`, both under `CLAUDE_CONFIG_DIR` if set	Keychain on macOS, or `~/.claude/.credentials.json` when the Keychain rejects the write (locked in an SSH session, for example). On Linux, always that file	Documented
Claude Desktop	macOS: `~/Library/Application Support/Claude/`. Linux (beta): `${XDG_CONFIG_HOME:-~/.config}/Claude/`	Electron cookies and Local Storage, extension secrets encrypted with `safeStorage`	MCP config documented, rest observed
ChatGPT desktop, macOS only	`~/Library/Application Support/com.openai.chat/`, `~/Library/Group Containers/2DC432GLL2.group.com.openai.chat/`, `~/Library/Preferences/com.openai.chat.plist`	Keychain items in OpenAI’s access group	Observed
Codex desktop, macOS only	`~/Library/Application Support/Codex/`, plus `~/.codex`	Shared with Codex CLI	Observed
Codex CLI	`${CODEX_HOME:-~/.codex}`. `CODEX_SQLITE_HOME`, `sqlite_home` and `log_dir` can move parts of it	`auth.json` in `file` mode or as the `auto` fallback; `.credentials.json` for MCP OAuth without a keyring	Documented and source

Desktop sessions that run Claude Code write to ~/.claude/, not to the Electron folder, so include both.

What to back up and what to leave out

Treatment	Claude Code	Codex
Back up, versioned	`settings.json`, `CLAUDE.md`, `rules/`, `skills/`, `commands/`, `agents/`, `workflows/`, `output-styles/`, `keybindings.json`, `projects/*/memory/`, `agent-memory/`, `plugins/installed_plugins.json` as a manifest	`config.toml`, `*.config.toml`, `hooks.json`, `rules/`, `skills/`, agent-role files
Back up after a secret check	`~/.claude.json` (personal MCP servers, trust decisions)	MCP `env` blocks in `config.toml`
Optional, encrypted, short retention	`projects//.jsonl`, `subagents/`, `tool-results/`, `history.jsonl`	`sessions/YYYY/MM/DD/rollout-*.jsonl`, `archived_sessions/`, `history.jsonl`
Exclude	`.credentials.json`, `file-history/`, `paste-cache/`, `debug/`, `shell-snapshots/`, `session-env/`, `backups/`	`auth.json`, `.credentials.json`, `log/`, `logs_2.sqlite`, `shell_snapshots/`, `packages/`, caches

For Claude Desktop, keep claude_desktop_config.json after checking its MCP env blocks, plus a list of installed extensions and where each came from. Reinstall extensions instead of restoring their executable caches. The ChatGPT app’s local databases are caches of a server-side account; use the account’s data export for conversations you want to keep.

Why copying the whole folder is the wrong default

Transcripts are plaintext. Anthropic’s docs say that anything passing through a tool is written to the session .jsonl, so a .env file a tool reads or a token a command prints is in there. Codex rollouts record tool activity the same way.

Your backup also keeps transcripts after the client has deleted them. Claude Code deletes transcripts after cleanupPeriodDays (default 30), but keeps sessions started, or last continued in Claude Desktop or Cowork at any age unless you set desktopSessionCleanupPeriodDays. A backup with a year of history still holds a transcript eleven months after the client deleted it.

A restore can also run code. Hooks, MCP server commands, skills, plugins, desktop extensions, and shell snapshots all execute something. If malware edited them, a full restore puts it back on the clean machine.

The Keychain protects less than it seems to. It stops someone who copies the disk offline, but malware running as your user can still request the item. The Linux desktop build can also fall back to Chromium’s basic password store when no wallet is running.

Dead ends worth skipping

Guessing Linux paths from macOS ones. Replacing Library/Application Support with .config works for Claude Desktop, which has a Linux beta. OpenAI ships no Linux desktop app for ChatGPT or Codex. The Codex source has Linux branches, but there is no supported Linux build. On Linux, your ChatGPT state lives in the browser profile.
Copying only the .sqlite files. Codex keeps state in state_5.sqlite, thread_history_1.sqlite, memories_1.sqlite and others . A live copy without the -wal and -shm sidecars can be incomplete or corrupt. Stop the client and copy all three.
Treating the desktop database as the archive. The Codex desktop app can rebuild its index from the rollout JSONL files, but metadata that lives only in the database is lost, back up the JSONL files.
Assuming claude purge cleaned everything. It doesn’t touch shell-snapshots/, backups/ (older copies of ~/.claude.json) or files written by /heapdump. According to Anthropic, a heap snapshot contains the full conversation and any credentials the process held.

Restore into a staging profile

Reinstall the signed apps, plugins, and extensions from their sources.
Restore your config, then read every hook, MCP command, and executable path before the first launch.
Restore transcripts or memory only if you need them.
Log in again. Don’t restore auth.json, .credentials.json, cookies, or Keychain exports.
Resume one session and confirm that it uses the right account and repository.

Verify the backup set

To list what exists and how large it is, without printing any contents, run this on the machine you back up:

for p in "${CLAUDE_CONFIG_DIR:-$HOME/.claude}" "$HOME/.claude.json" \
 "${CODEX_HOME:-$HOME/.codex}" \
 "${XDG_CONFIG_HOME:-$HOME/.config}/Claude" \
 "$HOME/Library/Application Support/Claude" \
 "$HOME/Library/Application Support/Codex" \
 "$HOME/Library/Application Support/com.openai.chat" \
 "$HOME/Library/Group Containers/2DC432GLL2.group.com.openai.chat"; do
 [ -e "$p" ] && du -sh "$p"
done

Then check that no login file ended up in the backup:

find /path/to/mounted/backup \( -name .credentials.json -o -name auth.json \) -print

It should print nothing. If it prints anything, that backup is a credential store: encrypt it, shorten its retention, or rotate the logins.

If malware may already have run

Don’t treat a restore as the cleanup. From a clean device, revoke your Claude and ChatGPT sessions, then rotate API keys, MCP and connector credentials, and any secret that appeared in a transcript or in tool output. Any backup the malware could reach counts as exposed. Rebuild the user profile, restore only config you have reviewed, and log in again.

Caveats

Paths and retention rules change between releases. The ChatGPT and desktop paths come from build inspection, not from a published schema, so check them against your installed versions before you write a backup job. Sources: the .claude directory reference , Claude Code credential management , Codex config and state locations , Codex credential storage , Claude Desktop MCP config paths , and Electron’s app.getPath() .

Back up the config you wrote, and leave out the files the app uses for login. Run the find check above against your latest backup tonight.

"No route to host" only for the AI agent: macOS Local Network privacy

Sat, 17 Oct 2026 22:30:00 +0200

My coding agent couldn’t reach anything on my home network:

nc: connectx to 192.168.0.2 port 22 (tcp) failed: No route to host
ping: sendto: No route to host

The router answered, and arp -an listed the server’s MAC address. In my own Terminal, the same ssh command connected. If you see this on a Mac and only your agent sees it, your network is fine. macOS is blocking the app the agent runs in because that app doesn’t have the Local Network permission.

The setup

macOS 27 on Wi-Fi
Claude Code in its VS Code extension, so every command the agent runs is a child process of VS Code
Targets on the Mac’s own subnet: a Linux server, a NAS, a second router

What went wrong

The agent was helping me with a server that really was down (that story is here ). It probed the subnet from the Mac, found that only the router answered, and reported with confidence that “the Mac reaching only [the router] looks like client isolation on the Wi-Fi. That’s usually a guest network.” It told me to join a different network.

I wasn’t on a guest network, and I said so. The agent looked again and noticed what rules the network out: ping itself failed with sendto: No route to host. That message comes from the local sendto() call, so the Mac refused to send the packet at all. Client isolation drops packets in the access point, and then ping reports Request timeout, not a send error. The target’s MAC was already in the ARP table, so the kernel knew exactly where to send it.

So the block was at the MAC, and every TCP test the agent ran from there was worthless.

Later that evening, in a new session, it happened again with a different host on the same subnet. This time the agent suspected its own sandbox and retried with the sandbox off. Same error. What settled it was my reply: the same ssh command works in my Terminal.

Fix

Open System Settings → Privacy & Security → Local Network and turn on Visual Studio Code (or whichever app hosts your agent). The agent’s next ssh went through. If yours still fails, restart the app.

The app can be missing from the list if macOS never showed it the permission prompt. Apple’s TN3179 notes that the prompt doesn’t appear when a very short-lived process makes the request, and most agent commands exit right after they fail. Since macOS 27.2, the list includes a + button to add an app yourself.

Why only the agent

Local Network privacy covers traffic to addresses on a Wi-Fi or Ethernet network that goes directly to the host, not through a router. TN3179 lists who gets access without asking:

daemons started by launchd
programs running as root
“command-line tools run from Terminal or over SSH, including any child processes they spawn”

Everything else is charged to its “responsible code”. If an app spawns a helper and the helper connects to a local address, macOS checks the app’s permission. The agent’s shell is a child of VS Code, so ssh, nc, and ping run there under VS Code’s permission. The same binary, run by the same user from Terminal, is allowed.

That explains the other half of the symptom. Internet traffic goes through the router, so it isn’t local and works fine. TN3179 also exempts the device’s DNS server when it sits on the local network, and a home router is usually the DNS server it hands out by DHCP. That is probably why the router was the one host still reachable, and it is exactly how client isolation looks from the inside.

The same trap waits for any agent or tool that an app such as an IDE starts on macOS.

Check before you blame the network

Run ping from the agent’s shell. sendto: No route to host for a host on your subnet whose MAC is in arp -an means the Mac refused to send it.
Run the same command in Terminal. If it works there, check the app’s Local Network permission.
If it fails in Terminal too, the cause is the network or the routing table. Later that same evening, another VPN came up as utun6 and took the default route, which cut the whole Mac off from the subnet. This time the agent caught it in netstat -rn -f inet.

Takeaway

On macOS, an app without the Local Network permission gets No route to host for hosts on your subnet, and so does every tool it spawns. An agent running inside that app will diagnose a working network as broken.

If your agent runs inside an app on macOS, open Privacy & Security → Local Network now and check that the app is on the list and switched on.

"Ansible requires blocking IO on stdin/stdout/stderr" when an AI agent runs Ansible

Tue, 13 Oct 2026 22:34:00 +0200

The first time my coding agent ran Ansible, every command failed before Ansible had read a single file:

ERROR: Ansible requires blocking IO on stdin/stdout/stderr. Non-blocking file handles detected: <stdout>, <stderr>

--syntax-check too, and even ansible --version. If you see this from an agent, a CI job, or a wrapper script, Ansible isn’t broken. The process that started it handed it non-blocking file handles, and a few shell redirections replace them.

The setup

ansible-core 2.20 (Ansible 13.3.0 from Homebrew) on macOS
A coding agent (Claude Code in VS Code) that runs commands in its own shell and captures their output

The check has been in every Ansible CLI entry point since ansible-core 2.14 (2022).

What went wrong

O_NONBLOCK is a flag on the open file, not on the process, so every child that inherits the file descriptor inherits the flag too. The agent’s harness connects the shell’s stdout and stderr to non-blocking pipes, and the shell passes them on unchanged to ansible-playbook.

At startup, Ansible calls os.get_blocking() on each of the three handles and exits if any of them is non-blocking. The list at the end of the message names the handles that failed. That makes it a good diagnostic: the first failure in my session listed only <stderr>, because the command was ansible --version | head -3. The pipe to head had already given stdout a fresh, blocking handle, while stderr still pointed at the agent’s pipe.

Run this in the shell you suspect to see which handles are affected:

python3 -c 'import os; print([os.get_blocking(fd) for fd in (0, 1, 2)])'

False in any position means Ansible will refuse to start there.

Fix

Give Ansible three handles the shell creates itself:

ansible-playbook site.yml </dev/null 2>&1 | cat

| cat gives stdout a new pipe, which is blocking.
2>&1 sends stderr into that same pipe. | cat alone fixes only stdout.
</dev/null replaces stdin. My agent’s stdin was never flagged, but Ansible checks it too, and an agent can’t answer a prompt anyway.

The pipe has a side effect: the command’s exit status is now cat’s, which is 0. A failed playbook looks like a success unless you turn on pipefail (bash and zsh both have it):

set -o pipefail
ansible-playbook site.yml </dev/null 2>&1 | cat

To check the fix without touching your real shell, you can make all three handles non-blocking for a single command and try it:

NB='import os,sys; [os.set_blocking(fd, False) for fd in (0,1,2)]; os.execvp(sys.argv[1], sys.argv[1:])'
(python3 -c "$NB" ansible --version) 2>&1 </dev/zero | cat
# ERROR: ... Non-blocking file handles detected: <stdin>, <stdout>, <stderr>
(python3 -c "$NB" sh -c 'ansible --version </dev/null 2>&1 | cat') 2>&1 </dev/zero | cat
# ansible [core 2.20.1] ...

The outer | cat and </dev/zero keep the flag on throwaway handles, so your terminal stays blocking.

Why Ansible insists

The pull request that added the check explains it. On a non-blocking stdout, a large write can fail partway with [Errno 11] write could not complete without blocking, and Ansible’s output gets cut off, or the run dies with an “Unexpected Exception”. The check turns those intermittent failures into one clear error at startup. The PR names another way to end up there: ssh switches its handles to non-blocking while it runs and doesn’t always switch them back when it exits.

So the same error can turn up wherever a parent process hands down non-blocking pipes, CI runners included, or in a terminal after an ssh that didn’t clean up.

Make the agent remember it

The agent worked this out within two minutes, and later that night it wrote the fix into the project’s skill for provisioning VMs:

Run Ansible from Claude Code with `</dev/null` and pipe its output through `cat`.

The next morning, a session about a different service ran ansible-playbook --syntax-check without the redirections and hit the same error. It never loaded the VM skill, so it never saw the line. A rule about how to run a tool belongs in the file the agent reads in every session, not in the instructions for one task.

Takeaway

“Ansible requires blocking IO” means the process that started Ansible handed it non-blocking file handles. </dev/null 2>&1 | cat gives it blocking ones, and set -o pipefail keeps a failed run from looking like a success.

If your agent runs Ansible, put that line in the instructions file it reads every session (CLAUDE.md or AGENTS.md).

APFS sparse bundle on SMB: rsync "Operation not supported (45)" and F_FULLFSYNC

Tue, 29 Sep 2026 12:55:00 +0200

A backup job that rsyncs into encrypted disk images on a NAS started printing this for every file (paths elided):

rsync: [generator] failed to set times on …
rsync: [receiver] mkstemp …
rsync: [generator] delete_file: unlink … failed: Operation not supported (45)

Then hdiutil attach for the next image hung for over ten minutes, and the two images whose rsyncs had finished stayed mounted.

If you keep APFS sparse bundles on an SMB share and see error 45 inside them, the files aren’t the problem. The share can’t do F_FULLFSYNC, and APFS can’t commit a single transaction without it.

The setup

macOS 27.0.1 dropped AFP, so an old NAS that speaks only SMB 2.1 got mounted over SMB instead. Each backup source has its own AES-256 sparse bundle on the share, created like this:

hdiutil create -encryption AES-256 -type SPARSEBUNDLE -size 50g \
 -fs APFS -volname app -stdinpass /Volumes/backup/staging/app.sparsebundle

The job attaches a bundle, rsyncs a server’s files into it, and detaches it.

The kernel log

rsync names the files, so the obvious suspects are permissions or the files themselves. The kernel log points at the image instead (timestamps shortened, process column removed):

/usr/bin/log show --last 90m --style compact \
 --predicate 'process == "kernel" AND eventMessage CONTAINS "apfs"'

12:43:53.531 disk7s1 mount-complete volume app, requested by: mount_apfs (pid 82535); parent: mount (pid 82534)
12:43:53.532 disk7s1 Host is remote
...
12:47:45.393 (apfs) tx_flush_thread:1678: disk7 tx_flush(8311) failed, 45, # 297
12:47:45.931 (apfs) tx_flush_thread:1678: disk7 tx_flush(8311) failed, 45, # 298

APFS noticed the image lives on a remote host. From 24 seconds after mounting, it failed to flush a transaction about twice a second, with error 45 (ENOTSUP). The second mounted image did the same. Nothing written inside them was being committed.

The probe

Error 45 from a flush suggested the sync call, not the write. This script tries plain fsync and the two stronger syncs macOS offers. Run it from a directory on the share:

import fcntl, os
p = "_synctest"
fd = os.open(p, os.O_RDWR | os.O_CREAT, 0o600); os.write(fd, b"x" * 4096)
for name, op in (("fsync", None), ("F_FULLFSYNC", 51), ("F_BARRIERFSYNC", 85)):
 try:
 os.fsync(fd) if op is None else fcntl.fcntl(fd, op)
 print(name, "OK")
 except OSError as e:
 print(name, "->", e)
os.close(fd); os.unlink(p)

fsync OK
F_FULLFSYNC -> [Errno 45] Operation not supported
F_BARRIERFSYNC -> [Errno 45] Operation not supported

APFS asks the disk image to flush; the disk image passes that on as F_FULLFSYNC on its band files on the share, and the SMB client says no.

The NAS also had a share called TimeMachineBackup, and Time Machine over SMB needs full sync, so it seemed worth a try. Same result. Its Time Machine backups dated from the AFP days.

What works

Keep the image off the share. The bundles moved to a USB drive, and every healthy one attaches, writes, deletes, and detaches fine there. That’s where the job runs now.

If the image has to stay on the share, use HFS+ inside it. A test bundle on the same share, created with -fs HFS+J instead of -fs APFS, passed everything the job does: rsync with --delete-during, rename, setting times, deletes, detach and reattach.

If the server runs Samba and you control it, fruit:time machine = yes on the share makes vfs_fruit advertise the FULLSYNC volume capability to macOS clients. That should let APFS images commit, but it wasn’t tested here.

Check the images you already have

The failed commits also left damage. When the bundles were copied to the USB drive, one of them wouldn’t mount:

hdiutil: attach failed - no mountable file systems

A read-only check of its volume (fsck_apfs -n) said why:

warning: (oid 0x74e6) om: btn: invalid o_cksum (0xdfbd1ccee26c9006)
** The volume /dev/rdisk8s1 with UUID … was found to be corrupt and cannot be repaired.

Its band files had last been modified during the failed SMB run, and the original on the NAS was identical, so the copy wasn’t to blame. Since it was only a staging mirror, it got recreated empty, and the next run filled it again. After any such episode, attach each image and run diskutil verifyVolume on it.

Why restic didn’t mind

Restic repositories on the same share were unaffected. Restic is written in Go, and Go’s Fsync on macOS tries F_FULLFSYNC and falls back to plain fsync on ENOTSUP. The comment in the Go source names this exact case: “There are scenarios such as SMB mounts where fcntl will fail with ENOTSUP.” APFS inside a disk image has no such fallback: when the full flush fails, it stops committing.

Takeaway

An APFS disk image on an SMB share works only if the share supports F_FULLFSYNC. Without it, every write inside the image fails with error 45, and the failed commits can corrupt the image.

If you’re moving sparse bundles from AFP to SMB, run the probe above on the new share before you mount anything on it.

macOS SMB: OSError: [Errno 9] Bad file descriptor after a silent reconnect

Tue, 29 Sep 2026 12:15:00 +0200

A Python script that had encrypted backup archives on a NAS for months started failing on every run:

Traceback (most recent call last):
 File "/Volumes/backup/./encrypt-one.py", line 74, in <module>
 main()
 File "/Volumes/backup/./encrypt-one.py", line 38, in main
 with open(f, "rb") as src:
OSError: [Errno 9] Bad file descriptor

Then the bash script that called it stopped too. Not intermittently: start the job and something fails sooner or later.

If you run long jobs from an SMB share on macOS and get EBADF on files that are plainly there, the cause is probably a session reconnect you never saw, and the kernel log is the only place that records it.

The setup

macOS 27 dropped AFP, so an old NAS that speaks only SMB 2.1 got mounted over SMB instead. A bash script on the share runs encrypt-one.py on a few archives in parallel with xargs -P. Each run streams a 600 MB archive from the share through openssl enc and writes the result back to the same share.

The dead end

The traceback points at open(), so the first move was to open and read that archive by hand. It worked, and so did a read under xargs -P 3. A file that opens fine and a job that fails anyway tells you the file isn’t the problem. Something happens to the handle while it’s open.

The kernel log

smbutil gave the first hint:

$ smbutil statshares -m /Volumes/backup
...
SMB_VERSION SMB_2.1
SESSION_RECONNECT_TIME 2026-09-29 12:01:17
SESSION_RECONNECT_COUNT 4

Four reconnects; the last one was inside the failed run. The kernel log explains what each one does (timestamps shortened, process column removed):

/usr/bin/log show --last 1h --style compact \
 --predicate 'process == "kernel" AND eventMessage CONTAINS[c] "smb"'

11:58:15.502 (smbfs) smb_iod_sendall: id 0 ts > iod_lastrecv && ts > sr_timesent.
11:58:15.502 (smbfs) smb_iod_reconnect: id 0 Starting reconnect with nas.local
11:58:15.502 (smbfs) smb2_smb_parse_change_notify: smb_rq_reply failed 60
11:58:16.523 (smbfs) smb_iod_reconnect: id 0 The negotiate succeeded to nas.local
11:58:17.065 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <archive.tar.bz2.enc.tmp>
11:58:17.173 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <backup.sh>
11:58:17.186 (smbfs) smb2fs_reconnect_dur_handle: Missing durable handle on <archive.tar.bz2>
11:58:17.205 (smbfs) smb_iod_reconnect: id 0: Reconnect completed successfully.
11:58:17.212 (smbfs) smb2_smb_read_write_async: smb_rq_reply failed 9
11:58:17.212 (smbfs) smbfs_do_strategy: archive.tar.bz2: READ failed with an error of 9
11:58:17.283 (smbfs) smbfs_do_strategy: archive.tar.bz2.enc.tmp: WRITE failed with an error of 9

The NAS stopped answering under sustained I/O (error 60 is ETIMEDOUT). macOS dropped the session and reconnected, and that part worked. Then it tried to reattach each open file; the server had nothing to reattach them to, and every read and write on those files failed with error 9, EBADF.

Look at the middle line: backup.sh is on the list. Bash reads a script from disk as it runs, so the script file is open the whole time and goes bad with everything else. That’s why the shell stopped as well.

Why

A durable handle is how an SMB 2.x client keeps an open file across a dropped connection: the server holds the open for a while, and the client reclaims it after reconnecting. This server granted none. So “Reconnect completed successfully” is true for the session and useless for every file that was open at the time. Nothing reaches the application except EBADF on the next read or write.

What fixed it

Stop running long I/O jobs from the share. The pipeline moved to a USB drive, and only finished files go to the NAS. That ended the failures.

If you can’t move off the share, two workarounds got the job past the failing step:

Make bash read the whole script before it starts, so it never goes back to the share for the next line:
```
#!/usr/bin/env bash
{
set -euo pipefail
# ... the whole script ...
exit
}
```
Bash parses the entire { } block before running any of it, and the exit stops it from reading past the closing brace.
Make the I/O survive a reconnect: process the file in segments (64 MiB worked), open, write and fsync each segment separately, and on EBADF, EIO or EAGAIN reopen and retry only that segment. With AES-CBC you can chain the segments by using the last ciphertext block as the next IV, and the output is byte-identical to one openssl enc pass. In the test run on the share, no reconnect happened at all, probably because the per-segment fsync slowed the writes enough for the NAS to keep up.

If the server is a Samba box you control, check whether it grants durable handles: the durable handles option only takes effect with kernel oplocks = no, kernel share modes = no and posix locking = no. Turning off SMB signing on the client (signing_required=no in /etc/nsmb.conf) might also take enough load off a weak NAS CPU to prevent the stalls. Neither was tried here.

Takeaway

On macOS, an SMB reconnect to a server without durable handles invalidates every open file on the share, including a running shell script, and the only trace is Missing durable handle in the kernel log.

If you’ve seen Errno 9 on an SMB mount, run smbutil statshares -a and look at SESSION_RECONNECT_COUNT before you debug your code.

Zero failures is suspicious: agent checks that silently ran nothing

Tue, 29 Sep 2026 12:05:00 +0200

My coding agent ran each of the two flaky Rust tests 150 times and got this:

streamed_read_right_after_a_rename: 0/150 failed
renames_are_combined_across_changes_they_do_not_depend_on: 0/150 failed

Its next message was “Zero failures is suspicious.” It was right: neither test had run once. In the same week, three of its checks gave a tidy answer (nothing found, all passed, all failed) that came from a broken command, and each broken command hid its own error.

If your agent’s output has (eval):log:1: too many arguments, 0 passed; 0 failed; … filtered out or argument list too long somewhere above the summary, the summary is about a check that never ran.

The setup

Claude Code 2.1.283 on macOS, where the agent’s shell is zsh 5.9
A Rust workspace whose test binary is run directly from target/debug/deps

Trap 1: zsh has a `log` builtin

The agent was debugging an FSKit file system extension and searched the unified log for sandbox denials:

log show --last 30m --style compact --predicate 'process == "MyFS"' 2>/dev/null | tail -40

Nothing came back, and the agent told me: “No log entries so far.” Half a minute later it ran log stream … > /tmp/fs.log 2>&1 & and read the file. Its first line was:

(eval):log:1: too many arguments

zsh has a builtin called log that lists the logins watch reports. Builtins win over $PATH, so log show never reached /usr/bin/log, and 2>/dev/null threw away the only sign of it. You can check your own shell:

$ zsh -c 'whence -wa log'
log: builtin
log: command

With /usr/bin/log, the denial showed up at once, and the agent corrected its earlier claim. The same error turned up in a different project’s session days later.

Trap 2: `cargo test --exact` with the wrong path passes

The 150-run loop called the test binary like this:

$B --exact tests::$t -q > /tmp/out_$t.txt 2>&1 || f=$((f+1))

With --exact, the filter has to equal the full test path. The tests live in vfs::tests, so tests::streamed_read_right_after_a_rename matched nothing, and libtest treats that as success:

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 93 filtered out; finished in 0.00s

Exit code 0, every time. Without --exact, the same filter would have matched as a substring. The agent listed the real names with $B --list, fixed the prefix, and the races then showed up under load.

Trap 3: an empty variable makes everything fail

After the fixes, the agent stress-ran the suite 400 times and looked up the binary first:

B=$(ls -t target/debug/deps/storage_core-* | grep -v '\.d$' | head -1)

The glob had grown past what ls accepts:

(eval):1: argument list too long: ls

failed runs: 400 / 400

$B was empty. zsh drops an empty unquoted word, so each run executed vfs::tests -q, got command not found into a log file nobody read, and counted as a failure. This time the agent saw the error right above the count and called the result bogus.

Fix

Make every check prove that it ran before you trust what it says.

Call /usr/bin/log by its full path, or put command in front of it, and keep stderr visible while you are still debugging:

/usr/bin/log show --last 30m --style compact --predicate 'process == "MyFS"' | tail -40

Count the tests that ran, not only the failures. One test per run should say 1 passed:

$B --exact vfs::tests::$t -q > /tmp/out_$t.txt 2>&1 || f=$((f+1))
grep -q '1 passed' /tmp/out_$t.txt || { echo "$t did not run"; exit 1; }

Get the binary path from cargo instead of a glob, and stop if it is empty:

B=$(cargo test -p storage-core --lib --no-run 2>&1 | grep -o 'target/debug/deps/storage_core-[0-9a-f]*')
: ${B:?test binary not found}

For the agent, add one line to its instructions file (CLAUDE.md or AGENTS.md):

When a check finds nothing, passes everything, or fails everything, first show that it ran:
how many items it checked, and that a known-bad input fails it.

Why it happens

All three are the same bug: the harness failed, and the failure looked like a result. A loop that counts exit codes can’t tell “no failures” from “no tests”, and a pipeline that ends in 2>/dev/null | tail can’t tell “no matches” from “no command”. Agents write exactly these one-liners, in zsh, many times per session, and they report what the last line printed.

The agent caught two of the three because the number looked wrong: zero out of 150 for known flaky tests, 400 out of 400 for a suite that had just passed. An empty log search looked plausible, so it went to the user as a finding.

Takeaway

A clean result from a check you haven’t seen fail is not evidence. Before you believe “nothing found” or “0 failed”, look for the count of what was checked.

Next time your agent reports zero failures, ask it how many tests actually ran.

FSKit after mount -F: "ls: fts_read: Operation not permitted"

Sat, 26 Sep 2026 16:30:00 +0200

My new FSKit filesystem mounted without complaint, but nothing inside it could be read:

$ ls -la ~/mnt/storage-test
ls: fts_read: Operation not permitted
total 0
$ cat ~/mnt/storage-test/sub/a.txt
cat: /Users/me/mnt/storage-test/sub/a.txt: Operation not permitted

stat on the mount point worked. If your FSKit extension does the same after a mount -F from the command line, check its sandbox before your code: the extension can see the source folder’s metadata but may not read its contents.

The setup

macOS 26, a file system extension built on FSKit’s FSUnaryFileSystem that exposes a local folder through a mount point
A small host app, StorageHost.app, in /Applications; its executable runs mount -F -t storagefs <source> <mount point>
The extension StorageFS.appex with the FSKit entitlement and the app sandbox
Info.plist with FSSupportsPathURLs set to true and FSRequiresSecurityScopedPathURLResources set to false

What went wrong

The first mount was over ~/Downloads, so the obvious suspect was privacy protection (TCC) for that folder. A fresh ~/storage-test with one file in it failed the same way, which ruled TCC out and pushed the search elsewhere.

My coding agent’s first log queries came back empty, and it told me there were no log entries. That was wrong. In zsh, log is a builtin, so log show ... 2>/dev/null runs the builtin, sends its too many arguments error to /dev/null, and prints nothing. Call /usr/bin/log by its full path. With that, the kernel had the answer:

kernel (Sandbox) 3 duplicate reports for Sandbox: StorageFS(83505) deny(1) file-read-data /Users/me/storage-test

The extension’s own log showed the failures from FSKit’s side: readDirectory:...reply:error:1 and readFrom:...reply:error:1. Error 1 is EPERM, which ls turns into fts_read: Operation not permitted.

Fix

mount -F gives the extension a plain path, not a security-scoped URL, so a sandboxed process can’t read an arbitrary path. For development, grant temporary sandbox exceptions in the extension’s .entitlements file:

<key>com.apple.security.temporary-exception.files.home-relative-path.read-write</key>
<array>
	<string>/</string>
</array>
<key>com.apple.security.temporary-exception.files.absolute-path.read-write</key>
<array>
	<string>/Volumes/</string>
</array>

This covers your home folder and external drives. It doesn’t override privacy protection, so ~/Downloads, ~/Documents, and ~/Desktop may still be refused; test with a folder elsewhere. Temporary exceptions are for development on your own machine. A shipping extension should use security-scoped resources instead. FSRequiresSecurityScopedPathURLResources in Info.plist requests that; I haven’t managed a clean test yet (see below).

The same logs flagged two more problems that I fixed along the way:

-[FSModuleVolume(Project) getMaxFileSizeInBits]: Volume implements neither maxFileSizeInBits nor maxFileSize. One of them must be implemented.
-[FSVolumeConnector getStandardItemAttributesForItem:replyHandler:]_block_invoke: Reported attributes are incomplete

The first needs maximumFileSizeInBits on the volume. The second went away once the item attributes set flags, which cleared the log entry.

Reinstalling switches the module off

To test each change, I replaced the app: rm -rf /Applications/StorageHost.app, copied the new build, and launched it once. After that, mount failed outright:

Module com.example.storage.fs is disabled!
mount: Unable to invoke task

pluginkit disagreed. pluginkit -e use -i com.example.storage.fs succeeded, and pluginkit -m listed the extension with a +, which means enabled. FSKit still refused. It keeps its own switch in System Settings → General → Login Items & Extensions → File System Extensions, and I didn’t find a command-line way to flip it. After I turned StorageFS back on there, the next mount listed and read files, and appends, renames, truncation, and an 8 MB write-and-readback all worked.

The disabled module also spoiled my one test of security-scoped resources. With FSRequiresSecurityScopedPathURLResources set to true, mount failed with Unable to invoke task, but the reinstall had just switched the module off, so the failure says nothing about the setting.

Why

An FSKit module is an app extension, and FSKit requires it to run in the app sandbox. When an app hands a folder to the extension, sandbox access can travel with it as a security-scoped URL. mount -F on the command line passes only a string. The sandbox lets the extension look up metadata for that path, which is why the mount and stat worked, and denies file-read-data, which every directory listing and file read needs.

Takeaway

If an FSKit mount works and every read returns Operation not permitted, search the kernel log for deny(1) file-read-data with /usr/bin/log, then give the extension sandbox access to the source path. After every reinstall, check the File System Extensions switch before you trust a test result.

If you’ve got FSRequiresSecurityScopedPathURLResources working with a command-line mount -F, I’d like to hear how.

ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY: your coding agent's pnpm 11 is not your pnpm 10

Mon, 06 Jul 2026 15:04:00 +0200

A coding agent ran pnpm test in my repo and got this:

Scope: all 6 workspace projects
[ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY] Aborted removal of modules directory due to no TTY

If you are running pnpm in CI, set the CI environment variable to "true", or set "confirmModulesPurge" to "false".

The stack trace ended in runDepsStatusCheck (.../node_modules/.pnpm/pnpm@11.7.0/...). My package.json says "packageManager": "pnpm@10.33.0", and pnpm -v in my terminal prints 10.33.0.

If you see this error only inside an agent, the agent is running its own pnpm, and following the hint makes things worse.

The setup

macOS, pnpm 10.33.0 through Corepack, a pnpm monorepo with a Next.js 15 app
The Codex desktop app, which ships its own Node 24 and pnpm under ~/.cache/codex-runtimes/codex-primary-runtime/dependencies/: pnpm 11.7.0 in July, 11.25.0 in October
The agent runs pnpm test without a TTY

What went wrong

The agent followed the hint and reran with CI=true pnpm test. pnpm stopped asking and did what it had wanted to do from the start:

Recreating /Users/me/project/node_modules
Progress: resolved 378, reused 0, downloaded 137, added 12
...
[WARN] GET https://registry.npmjs.org/@next/swc-darwin-arm64/-/swc-darwin-arm64-15.5.19.tgz error (ERR_PNPM_ENOSPC). Will retry in 10 seconds. 2 retries left.
[WARN] GET https://registry.npmjs.org/next/-/next-15.5.19.tgz error (ERR_PNPM_ENOSPC). Will retry in 10 seconds. 2 retries left.
...
Progress: resolved 378, reused 0, downloaded 377, added 377, done

[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: cpu-features@0.0.10, esbuild@0.21.5, esbuild@0.28.1, protobufjs@7.6.4, sharp@0.34.5, ssh2@1.17.0

It deleted node_modules and downloaded every package again (reused 0) into a second store, and the disk ran out on the way. It left an untracked .pnpm-store/ in the repo and wrote placeholders into the tracked pnpm-workspace.yaml:

allowBuilds:
 cpu-features: set this to true or false
 esbuild: set this to true or false
 protobufjs: set this to true or false
 sharp: set this to true or false
 ssh2: set this to true or false

No tests ran. After that, even pnpm exec tsc --noEmit failed with the same NO_TTY error, so the agent switched to ./node_modules/.bin/tsc and ./node_modules/.bin/vitest, reverted the YAML, deleted .pnpm-store/ and committed with only the focused tests green.

Ten weeks later, next build failed:

 ⚠ Attempted to load @next/swc-darwin-arm64, but it was not installed
 ⨯ Failed to load SWC binary for darwin/arm64, see more info here: https://nextjs.org/docs/messages/failed-loading-swc

The July install had ended one package short (378 resolved, 377 added), and the SWC binary was one of the two downloads that hit ENOSPC. A later agent session “fixed” the build by installing the binary into /tmp and symlinking it into node_modules, a fix that lasts until macOS cleans /tmp.

Fix

First, ask the agent’s shell which pnpm it gets:

command -v pnpm
pnpm -v

Then make the agent use your version. Corepack reads packageManager, whatever is first on PATH:

corepack pnpm test # runs pnpm 10.33.0

Write that into AGENTS.md (or your agent’s equivalent), along with one rule: if pnpm wants to remove node_modules, stop and report.

To make the bundled pnpm harmless as well, turn off the automatic install in pnpm-workspace.yaml:

verifyDepsBeforeRun: false

That is the pnpm 10 default, so nothing changes for you. I checked it with the bundled pnpm 11.25.0: with the setting, it runs the script; without it, it installs first.

If you already followed the hint, clean up with your own pnpm:

git checkout -- pnpm-workspace.yaml
rm -rf .pnpm-store
corepack pnpm install --frozen-lockfile

Run that in a terminal. If pnpm asks to remove node_modules, say yes; this time it rebuilds against your own store.

Why

Three pnpm 11 changes line up:

verify-deps-before-run defaults to install (pnpm 10: false). pnpm test and pnpm exec check node_modules first and install if anything is off.
pnpm 11 uses store v11; pnpm 10 uses v10. node_modules/.modules.yaml records the store it was linked from, so to pnpm 11 a working pnpm 10 install looks incompatible and has to be purged. confirmModulesPurge defaults to true; a purge without a TTY aborts, and CI=true drops the confirmation but not the purge.
Ignored build scripts are an error, and pnpm writes the allowBuilds placeholders for you to fill in.

On my Mac, the two stores now sit side by side in ~/Library/pnpm/store/: 851 MB in v10, 588 MB in v11.

Why didn’t packageManager catch it? pnpm 11 does honor it: run the bundled binary directly and pnpm -v prints 10.33.0, because it switches to the pinned version. The wrapper in the October runtime turns that off:

#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
export pnpm_config_pm_on_fail=ignore
exec "${SCRIPT_DIR}/../../node/bin/node" "${SCRIPT_DIR}/../../node/node_modules/pnpm/bin/pnpm.mjs" "$@"

The environment variable beats anything in the repo. With pmOnFail: error in pnpm-workspace.yaml, or devEngines.packageManager with "onFail": "error", the wrapper still runs 11.25.0.

Takeaway

An agent runtime can bring its own toolchain and switch off the check that would have caught it. When an agent reports “tests blocked by the environment”, find out which binary it ran before you believe the report.

Run pnpm -v in your agent’s shell today and compare it with packageManager.

Macos on Lessons learned

Backing up ~/.claude and ~/.codex without archiving your AI logins

Where AI client state lives on macOS and Linux

What to back up and what to leave out

Why copying the whole folder is the wrong default

Dead ends worth skipping

Restore into a staging profile

Verify the backup set

If malware may already have run

Caveats

"No route to host" only for the AI agent: macOS Local Network privacy

The setup

What went wrong

Fix

Why only the agent

Check before you blame the network

Takeaway

"Ansible requires blocking IO on stdin/stdout/stderr" when an AI agent runs Ansible

The setup

What went wrong

Fix

Why Ansible insists

Make the agent remember it

Takeaway

APFS sparse bundle on SMB: rsync "Operation not supported (45)" and F_FULLFSYNC

The setup

The kernel log

The probe

What works

Check the images you already have

Why restic didn’t mind

Takeaway

macOS SMB: OSError: [Errno 9] Bad file descriptor after a silent reconnect

The setup

The dead end

The kernel log

Why

What fixed it

Takeaway

Zero failures is suspicious: agent checks that silently ran nothing

The setup

Trap 1: zsh has a log builtin

Trap 2: cargo test --exact with the wrong path passes

Trap 3: an empty variable makes everything fail

Fix

Why it happens

Takeaway

FSKit after mount -F: "ls: fts_read: Operation not permitted"

The setup

What went wrong

Fix

Reinstalling switches the module off

Why

Takeaway

ERR_PNPM_ABORTED_REMOVE_MODULES_DIR_NO_TTY: your coding agent's pnpm 11 is not your pnpm 10

The setup

What went wrong

Fix

Why

Takeaway

Trap 1: zsh has a `log` builtin

Trap 2: `cargo test --exact` with the wrong path passes