AI Coding File I/O: Decide Between macOS and Linux

AI coding agents often wait on filesystem metadata before they wait on the model or the CPU. A typical loop creates a worktree, installs dependencies, and then deletes the tree. Each step touches a huge number of tiny directory entries. The useful technology question is not “is a Mac slow.” It is which of those three operations is slow on your repository.

📑Table of Contents

1. Public numbers at a glance
2. Why AI agent workloads hit the filesystem first
3. How to turn the public bench into a decision
4. A stay-or-migrate checklist before you move to Linux
5. Practical options if you stay on macOS
6. FAQ
7. Summary

What each source is for

• The Neuron (21 August 2026): independent same-week confirmation of large agent-performance gains after a move from macOS to Linux, especially from faster filesystem behavior.
• daily.dev restatement (20 August 2026): the public timing and storage table.
• BigGo Finance: a Japanese rewrite that circulated the same episode; treat it as discovery, not as independent measurement.

---

What this article covers

This article is a measure-first stay-or-migrate guide, not a straight Linux-migration walkthrough. It maps three decisions before any host change:

• How to read the public numbers
• When staying on macOS is rational
• The pre-Linux timing procedure: time worktree add, cached install, and clean/delete on your own repo, record the seconds, then choose stay on macOS, move only the agent execution layer to Linux, or split Mac-orchestrator plus Linux SSH

---

Public numbers at a glance

The published table is a demo log, not a ranking. Hardware and monorepo size differ. Use it to decide which operations to time on your machine.

Demo timings and storage

Operation	Public macOS figure	Public Linux figure	How to read it
Clean / delete	31s on M1 Max	6s on ext4 (Ryzen)	About 5x. Raw SSD speed is a weak explanation
node_modules install	44s on M1 Max	4.5s on ext4	About 10x, even with cache in the write-up
125 worktrees, disk	75GB on ext4	24GB on XFS+VDO	The ~3x cut assumes VDO. Plain ext4 grows
Worktree create with hard links	Reports of APFS getting worse	7s → 2.85s	Link strategy can flip sign by OS

Source: daily.dev (20 August 2026) (as of August 2026).

---

How not to read the table

The Neuron confirms a performance gap. It does not reprint this storage table. Do not treat either page as a guarantee for your laptop.

---

Why AI agent workloads hit the filesystem first

The mismatch is workload versus design goal, not a slogan about Macs.

git-worktree as the parallel-tree primitive

git-worktree is the official way to add a second working tree that shares one object database.

These commands are first-class:

• git worktree add
• git worktree remove
• git worktree list

Multiple checkout with submodules is still experimental. Agent farms sit on that primitive. For Git history and safety around agents, see Using Git with AI coding agents: history, worktrees, and guardrails.

---

pnpm stores and hard links

On the package side, pnpm’s git-worktrees guide documents the following setup:

• git clone --bare
• git worktree add
• enableGlobalVirtualStore: true

With the global virtual store, each tree’s node_modules symlinks into one content-addressable store. The default keeps a per-tree .pnpm store and uses hard links or copies.

The pnpm FAQ states:

• hard links make node_modules look large while sharing inodes
• a store on another filesystem falls back to copies
• do not share one writable store across mutually untrusted agents

---

What APFS is optimized for

Apple’s APFS role guide describes APFS as a proprietary filesystem designed with encryption in mind. It targets Apple devices.

Documented design goals include:

• Flash/SSD
• copy-on-write metadata
• clones
• snapshots
• coalesced I/O

It does not claim to be the fastest small-file store for developer agents. Do not read consumer flash goals as an agent-metadata SLA.

---

Time these three operations first

Time the three operations once on your own repo:

1. Add one worktree
2. Run a cached install
3. Clean / delete

Those three rows tell you which public line actually applies.

---

How to turn the public bench into a decision

Treat the numbers as a demonstration. Confirm the sign on your monorepo and package manager before you migrate.

What the restated numbers say

The daily.dev restatement reports:

• M1 Max clean 31s / install 44s versus AMD Ryzen ext4 6s / 4.5s (about 5–10x).
• 125 worktrees: 75GB on ext4 versus 24GB on XFS+VDO.
• XFS+LZ4/VDO as the suggested speed/space balance. ZFS and Btrfs are framed as a poor fit for this workload.
• Rift (Anomaly), a CoW helper for macOS worktrees, with a last commit about two months old and a note that it may be abandoned.

---

What the kernel VDO doc actually guarantees

First-party backing for the storage mechanism is the Linux kernel dm-vdo design document. VDO does the following at the block layer:

• inline deduplication
• compression
• zero-block elimination
• thin provisioning

Documented limits:

• max block size is 4K
• 254:1 dedup ceiling
• 14:1 compression ceiling

The lineage is Permabit (2009), production in 2013, open-sourced in 2017 after Red Hat acquired Permabit. The kernel page does not publish 24GB, 75GB, or any Mac timing. VDO proves Linux has a block-layer way to shrink copies. It does not prove every 125-worktree farm becomes one-third the size.

---

Three limits before you migrate

Three limits matter for AI / Linux decisions:

1. CPU and SSD are not matched. The 5–10x gap includes hardware.
2. The storage ratio assumes VDO. The same table shows 75GB on plain ext4.
3. Named clock-limited demos and suite labels stay inside secondary retellings. This article uses the daily.dev table, The Neuron confirmation, and official docs.

Fill four columns before you move production work: operation, your Mac time, a spare Linux box time, and the delta. An AI coding setup should change hosts only after that delta reproduces.

---

A stay-or-migrate checklist before you move to Linux

Do not move the whole laptop. Decide whether the agent execution layer can live on Linux.

Five checks

Use these five checks:

1. Do you keep 2–3 worktrees, or eight or more all day?
2. Does a cached pnpm install take more than 15 seconds?
3. Does clean/delete take more than 20 seconds?
4. Are leftover worktrees eating more than 1TB?
5. Do GUI or computer-use flows still need macOS?

If 2 or 3 stay above the threshold, clone the same repo on a spare Linux box and time the same three operations. If 1 is small and 5 is mandatory, cap worktrees before you migrate.

---

Related boundaries

Related boundaries:

• Harness-level instruction, guards, and verification belong in a different layer; see Harness design for a safe agent loop.
• Faster disks do not fix agents rewriting their own tests (spotting test-tampering in coding agents).

---

Spare-box procedure

A spare-box procedure is enough:

1. Install Linux. Use ext4 if you only care about speed. The public ext4 numbers are already fast.
2. Consider XFS plus VDO only when storage is the main pain.
3. git clone --bare, then git worktree add for each branch.
4. If you want the global virtual store, set enableGlobalVirtualStore: true in pnpm-workspace.yaml first, then pnpm install in each tree.
5. Remove finished trees with git worktree remove. Cheap trees still accumulate.

---

VDO operating cost

VDO is a block-layer optimizer. Backup, snapshot, and encryption operations get more expensive. A single-laptop shop may not win. Next action: measure the same repo on a spare box. Leave production on the current host until the four-column table is filled.

---

Practical options if you stay on macOS

Staying is a valid decision. Set a worktree cap and a hard-link policy first.

Useful cuts

Useful cuts:

• Prefer branch switches and stash if you do not need parallel trees. If you do, cap at two or three.
• Pin the pnpm store on the same volume as the project so installs do not copy across filesystems.
• Share a global virtual store only among agents you trust.
• Check maintenance before relying on a CoW helper such as Rift. Do not put a stalled repo on the production path.
• APFS clones and snapshots are strong for consumer workflows. They do not waive the agent tax.

---

Hard-link sign and host split

Public write-ups say enabling hard links on APFS can make install worse. Measure on and off once. If the sign flips, do not import the Linux 7s → 2.85s result.

If GUI work is the main job, keep the Mac as orchestrator and SSH the heavy execution to Linux. For an AI team, splitting layers is easier to reproduce than “move everything to Linux.”

---

FAQ

Should I expect the public 5–10x gap on my machine?

A. No. CPU, SSD, and monorepo size differ. Time the same three operations, then interpret the gap.

Source: daily.dev (20 August 2026)

---

Is a one-third storage cut normal?

A. That ratio is the 125-worktree XFS+VDO example. Plain ext4 in the same write-up is 75GB. Kernel docs guarantee ceilings of 254:1 dedup and 14:1 compression, not 24GB.

Source: daily.dev (20 August 2026) / dm-vdo design

---

Does this happen without pnpm?

A. It can, if you create and delete many small files. Hard-link behavior is package-manager specific. Measure the tool you actually use. pnpm documents a copy fallback when the store sits on another filesystem.

Source: pnpm FAQ / pnpm git worktrees

---

What is the shortest way to run more parallel agents on macOS?

A. Cap worktree count, keep the store on the same filesystem, and delete finished trees. Do those three before you install a CoW helper.

---

Does Apple say APFS is slow?

A. No. Apple documents encryption, flash, CoW, and snapshots as design goals. The slowness numbers are third-party benches. The Neuron also does not claim an official Apple verdict.

Source: Apple Platform Security — Role of Apple File System / The Neuron (21 August 2026)

---

Related articles:

• 13572
• 13549
• 13550

Summary

AI coding agents often stall on small-file metadata, not on the model. The public 5–10x timings and one-third storage cut belong to a specific demo and a VDO setup. This article is not a mandate to move everything to Linux.

Next action: time worktree add, cached install, and clean/delete on your own repo; record the seconds; then choose stay on macOS, move only the agent execution layer to Linux, or split Mac-orchestrator plus Linux SSH. If cached install stays over 15 seconds or clean stays over 20 seconds, repeat the same three operations on a spare Linux box. If those thresholds do not hold, stay and cap worktrees first. Consider VDO only when storage is the main goal; ext4 is enough when you only need speed.

The public numbers are one demo machine. Rift’s maintenance is unclear. Do not treat a finance-site headline or a bookmark count as a reason to migrate.