My Slow Local Pages Were Caused By Stuck Codex Shell Processes

My local dev pages had become really slow, a few seconds each, and the times were all over the place. I had just changed how one page loads its data, so I assumed I had broken something.

I asked Claude Code to find out why. It turned out the problem wasn’t my code at all. It was a pile of stuck processes left behind by ChatGPT Desktop in Codex mode, which I also have running on the same machine.

It wasn’t just the one page

My first guess was the page I had been changing. Claude timed it with curl a few times and it was slow, anywhere from 2.4 to 5.5 seconds.

Then it tried other pages, including ones that never touch the database:

• One page took 4 to 13 seconds
• Another took 2.5 to 8.9 seconds
• A page with no database access took 2.6 to 7 seconds, then 0.24 seconds a few requests later
• Static files like the favicon took about 0.2 seconds

So the server itself was fine and the slowness hit everything that had to do real work. It was also very inconsistent, which pointed away from a bug in my code and towards something else fighting for the machine.

What was eating the CPU

The next thing it checked was the machine rather than the site. The load average was around 125 on a 10 core Mac. That is not a number I want to see.

Looking at the busiest processes, there were 18 copies of zsh -lc all using somewhere between 40% and 90% of a core each. Some had been running for about 11 hours, and the oldest for over 4 days. Their parent was process 1, which means whatever started them had already gone.

The command line on each one was the same script, and it is Codex capturing a snapshot of my shell (aliases, functions, exported variables) so it can run commands in the same environment. That should take about a second. These had been going for days.

That would explain the slow and wildly varying page times, and it did. I killed them (the command is further down) and the pages went straight back to very fast.

It looks like a known bug

There is a GitHub issue on the Codex repo from 31 May 2026 that matches this closely. The reporter found orphaned /bin/zsh -lc snapshot processes with a parent of 1 each using roughly a full core, and killing them brought the CPU back. When I looked there was no response from the maintainers.

Mine were using less than a full core each, but the machine was so overloaded that they were all fighting each other, so I wouldn’t read much into that.

There are two other Codex issues about leftover processes burning CPU (#13928 and #14962), but those are about the main Codex program, not the shell snapshots. Related, but I wouldn’t call it the same bug.

How to check your own machine

Before you start optimising a slow page, have a look at what else the machine is busy doing.

uptime
ps -Ao pid,ppid,pcpu,etime,command | sort -k3 -nr | head

If the load average is way above your core count, or something odd has been running for days with a parent of 1, that’s your suspect. You can also sort by CPU in Activity Monitor.

For the Codex ones, this finds them:

pgrep -lf "print '# Snapshot file'"

Claude didn’t kill them for me. They belong to another tool, so it left that to me, which I was happy with. This is what I ran, and it stops just those snapshot processes:

pkill -f '__codex_snapshot_command'

I’d check the list first, though. A parent of 1 and a long run time are good signs, but they don’t prove a process is stuck.

Check the machine first

I have written before about slow Astro dev pages caused by barrel imports, and that is still worth checking if you see slow pages after an upgrade.

This time the lesson was to look at the machine before the code. I’d have spent a lot longer trying to speed up a page that was never slow.