Know what your agent CLI leaves behind

Before you roll a coding agent out to a team, find out what it writes to disk and what it leaves running. Here is what that looked like for three of them.

Why we looked

A Hacker News thread on 12 October was titled "Codex CLI installs a persistent, self-updating background daemon by default" (thread). That is a fair thing to worry about. A coding agent runs with your user's permissions, in your repositories, next to your keys. If it also starts something that outlives the session, you want to know before it is on fifty laptops.

So we measured. One idea runs through the results: a CLI's footprint is a default setting, and defaults are something you can check before rollout instead of discovering after.

What we ran

Three CLIs, on macOS, one run each, on 2026-10-13:

• Claude Code 2.1.296
• Codex CLI 0.160.0
• opencode v2.0.23

Each one started under env -i with a brand-new, empty HOME and TMPDIR, a minimal PATH and one canary environment variable. The working directory held a .env file with one fake key. The task was a single prompt: "Reply with the word ok." There was no login in the new HOME, so no model call succeeded. Each run was capped at 90 seconds.

After each run we recorded every file under the new HOME, TMPDIR and work directory; files changed since the start in the real HOME config folders, ~/Library/LaunchAgents and /tmp; launchctl list before and after; processes still alive five seconds after the CLI exited; and whether the canary value or the fake key showed up in any file the CLI wrote.

What we found

Codex CLI 0.160.0 wrote 5,483 files, about 100 MB, on first start. Most of it, 5,434 files and 94 MB, sat under .codex/.tmp/plugins. The rest included 49 bundled skills, seven SQLite databases, a session transcript and an installation id. It tried the API, got 401 Unauthorized, retried, and exited after 16 seconds.

Claude Code 2.1.296 wrote 4 files, 48 KB. It exited within a second with "Not logged in".

opencode v2.0.23 left a background server running after it exited. The process, opencode serve --service, was detached, had launchd (pid 1) as its parent, and was listening on 127.0.0.1. It wrote 7 files in total, about 21 MB including three runtime libraries in TMPDIR.

None of the three added a launchd job. None touched files outside the fresh HOME that we could find. None copied the canary value or the fake key to disk.

The near miss

What looked like the risk was a Codex daemon. In our run it was not there: no persistent codex process and no launchd job, in an unauthenticated run of 0.160.0. We did not reproduce the claim in the thread.

What we found instead was different on both sides. Codex's footprint was size: thousands of files on the first start, before any login. The process that stayed running belonged to a different CLI, and it was not a launchd job, so a check that only looks at LaunchAgents would have missed it. The thing to look for was not the thing in the headline.

Run it yourself before rollout

1. Start from a fresh HOME. Make an empty directory and mkdir -p <dir>/tmp, keep it free of any login (a logged-in HOME makes real model calls), run the CLI under env -i HOME=<dir> TMPDIR=<dir>/tmp PATH=<minimal>, and give it one trivial prompt.
2. Count the files. find <dir> -type f | wc -l and du -sh <dir> after it exits. Note what lands in databases, transcripts and caches.
3. Check processes after exit. Wait five seconds, then look for anything that references the fresh HOME or holds a new listening port. Detached processes with parent pid 1 are the ones to look at. If one remains, confirm it holds files under the test HOME, then stop it by pid.
4. Diff launchctl list. Save it before the run, save it after, and diff. Also list ~/Library/LaunchAgents by modification time.
5. Grep for a canary. Put a unique made-up value in an env var and a fake key in a .env, then grep everything the CLI wrote for both.

Repeat it per version: this was one run of one version each.

Limits

One run each, with no login. What a logged-in session does by default, including auto-update or other background work, was not measured. We did not trace system calls, which needs root, so "what it read" is limited to what ended up on disk. The Mac had other agents running; we attributed new processes only when they referenced the fresh HOME or matched a listening port. opencode's first run hit a port already held by an existing opencode service on the same Mac, so it was re-run on a different port; that re-run is the one reported.

What to take from it

None of this says a tool is unsafe. It says each one has a footprint, and you can measure the footprint yourself. If you run this check on a newer version or a logged-in session and see something different, publish it. Measured numbers with exact versions are what make threads like this one useful.

If your team is adding coding agents, deemwar builds agent security, access control and audit trails: https://deemwar.com/services?utm_source=deemwar&utm_medium=article&utm_campaign=cli-audit