Build1 distinct publisher3 min readPublished
A reproducible strace benchmark on a twenty-line validation task logged 752 attempted /proc/*/environ opens from Claude Code and none from Codex, which makes where an agent looks at startup a procurement question.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The /proc walk deserves the attention. The writeup calls it a design decision, distinguishing it from a leak: Claude Code walks /proc at startup to recover the variables its parent shell exported, since a terminal-launched process has no other route to them [10]. That reasoning covers one PID, or the ancestor chain above it. The trace instead records attempts against every process ID visible in /proc, starting at 1 [8]. Of the attempts, 256 returned data, a 34% hit rate [2], and those 256 are exactly the processes owned by the invoking user [8]. The same sweep collected stat, status and cmdline from PID 1 upward, which is the name, state and full command line of everything running on the box [13].
One of the 256 was gnome-keyring-daemon, the process that fronts the system keychain for SSH keys, GPG keys and Wi-Fi passwords [11]. Its environment holds DBUS_SESSION_BUS_ADDRESS and the rest of the addressing needed to reach the keyring over D-Bus, not the secrets themselves, which the author characterises as what an attacker would need to query it programmatically [12].
The published counts do not quite reconcile. 752 environ paths, plus stat, status and cmdline for the same PIDs, is 3,760 distinct /proc paths, against 2,779 unique files reported for the entire session [3]. Either the unique-file count excludes /proc, or the stat/status/cmdline sweep covered fewer PIDs than the environ sweep. The trace can settle that.
For the magnitudes to transfer, your process table has to resemble the test machine's: 752 is the size of /proc on a desktop Linux session, and 256 is the count of processes that session's user happens to own [8]. A CI container running the same agent has tens of processes and no keyring daemon to find. The behaviour transfers even where the magnitude does not, because the magnitude is a property of the host. Startup fan-out shows on the wire as well: one Claude Code connection went to a Google Cloud address that does not appear in Codex's trace [19].
Not all of the volume is the agent's doing. Both agents opened ~/.gitconfig and /etc/passwd, which the author attributes to the 14 to 18 subprocesses each spawned, every one resolving the user for itself [15]. ~/.npmrc contains a registry authentication token, and it was opened because npm was invoked once to check dependency state and reads its config unconditionally at startup [16]. That is npm's default, and a shell script would trip it too.
The nine-to-one ratio on unique files [1] is the least useful number in the set, and the author says as much, attributing most of Claude Code's volume to its own plugin cache, config files and module resolution [7]. Still, 2,779 files is generous reading for a one-file, twenty-line edit [20]. Between the two Claude Code runs the environ counts moved by four attempts and two successes [4], consistent with a fixed startup routine [9]. This is one machine and one task, measured by one publisher, and the reason to weigh the numbers at all is that the project and the analysis scripts were published [5].
Ranked by verification strength, evidence, and original report placement.
The benchmark used a small Node.js/Express user management service with a POST /users endpoint deliberately missing input validation; the identical task for both agents was to add validation for name, email and password and return 400 with a descriptive error for each failure case.
Each agent was run under strace -f, recording every openat, connect, execve and getdents64 call made by the agent process and every subprocess it spawned.
All runs used a fresh copy of the project, and Claude Code was run twice to check stability, with results within 0.5% across both runs.
The agents tested were Claude Code 2.1.72 and Codex CLI 0.113.02.
The benchmark project and the analysis scripts are published on GitHub so others can run it themselves.
Claude Code opened 2,779 unique files while editing one file; Codex opened 303.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 28, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
AgentCheck reviews what the agent actually changed, and does it without another model1 distinct publisher
build
A Timed-Out Reset SMS Is Not A Failed One, And Your Retry Code Probably Disagrees1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
build
The OTP send-storm is an admission bug: cooldowns belong in the transaction, not the countdown1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Auditable method, one laptop
Syscall traces are about as close to ground truth as this kind of claim gets, and dev.to did the things that make a measurement inspectable: named builds, fresh project per run, a repeat run within half a percent, and the harness on GitHub. What holds the score down is that all of it is one author on one GNOME desktop, and the writeup's own totals collide — 752 PIDs times four /proc files is 3,760 paths against a 2,779 session total.
Two runs, one machine, no takers yet
Observed uptake is the author's own three sessions: two Claude Code runs and one Codex run against shipping builds of both CLIs, plus a repository nobody in this reporting has been seen to clone. The MCP log files are the one piece of genuine field usage — a real workstation with Gmail and Calendar servers configured — and that is a sample of one desk.
Headline outruns the harm demonstrated
The title is a scoreboard — 752 attempted, 256 succeeded, Codex zero — while the body concedes the mechanism is legitimate environment inheritance and that reading gnome-keyring-daemon's environ yields D-Bus addressing, not keys. The author deserves credit for disclaiming his own biggest number as mostly plugin cache. Still, no data leaves the machine anywhere in this reporting, no vendor is asked whether the sweep is bounded, and 'procurement question' is doing rhetorical work the traces have not yet earned.
Self-published, undisclosed, one vendor loses
A single-author post on a developer publishing platform with a counter-style headline and a clean winner has obvious attention economics, and nothing states the author's relationship — or lack of one — to either vendor. Two things pull the other way: the repository is open for anyone to contradict him, and the shared-read section actively defuses the easiest cheap shots by calling ~/.gitconfig and /etc/passwd noise floor.
Replicable, but not yet replicated
We would stand behind the direction of this finding — Claude Code reads the process table at startup and Codex does not — because the method is the right one and the two runs barely moved. We would not yet stand behind the precise figures or the security conclusion: one machine, one desktop stack, no vendor response, and an internal count mismatch nobody has resolved.