Memory not reclaimed after codex-cli exits in non-interactive mode

The OS kernel is responsible for freeing all memory associated with a process with it terminates. Are you saying that the codex process isn't terminating? Or are there other processes that are started and not getting terminated?

@etraut-openai
The codex process terminates, and I don't see any other related processes, yet overall memory usage increases after each run.
I'm not a low-level programmer, so this might not be a traditional memory leak — however, I read similar symptoms can be caused by leftover shared memory or tmpfs objects that persist between runs.

If helpful, I can collect more info or run checks to confirm whether a shared memory segment or tmpfs object is being left behind.

I'm somewhat skeptical that this is a Codex issue based on what you're saying, so I think we'll need more proof before we spend time investigating this.

@etraut-openai
OK, I’ll gather some more information and get back to you. Thanks.

Hey, I'd like to help investigate this further.

The symptoms — memory growing across repeated runs even though the process exits cleanly — are consistent with leftover POSIX shared memory objects or tmpfs allocations that aren't cleaned up on exit.

@thingersoft, if you're able to run the following before and after each codex exec invocation, it would help narrow this down:

# Check shared memory segments
ipcs -m

# Check POSIX shared memory objects
ls /dev/shm

# Check tmpfs usage
df -h | grep tmpfs

If any entries appear after the run that weren't there before — and persist after the process exits — that would be concrete evidence of leaked resources and a clear starting point for a fix.

I can help interpret the output or dig into the Codex source to trace where shared memory or tmpfs might be allocated without a corresponding cleanup. Happy to assist if that's useful.

After further inspection I couldn't find any remaining artifacts.
The memory usage growth is still present, but it appears to be caused by processes unrelated to Codex execution.
I also found that some process exits with code 137 were due to the container lifecycle configuration rather than an OOM.
Because there's no evidence that Codex contributed to this issue, I'm closing it.
Thanks for your cooperation.

Forensic Update (artifact-backed, sanitized)

I re-analyzed the sysdiagnose archive (codex-watchdog.tar.gz) and corrected my earlier attribution.

Artifact 1: Panic excerpt (panic-full-2026-03-04-171042.0002.panic)

panic(...): watchdog timeout: no checkins from watchdogd in 90 seconds
Compressor Info: ... 100% of segments limit (BAD) with 38 swapfiles

Thread task pri cpu_usage
... codex-aarch64-apple-darwin 31 0
... gmail-rag 31 4926186

Interpretation: watchdog panic occurred under severe VM pressure; Codex was present at panic time, but this snippet alone does not prove primary causality.

Artifact 2: Pre-panic Jetsam timeline (JetsamEvent-2026-03-04-*.ips)

2026-03-04 16:36:33 +1100  largestProcess=gmail-rag
2026-03-04 16:38:09 +1100  largestProcess=gmail-rag
2026-03-04 16:42:26 +1100  largestProcess=gmail-rag
2026-03-04 16:44:51 +1100  largestProcess=gmail-rag
2026-03-04 16:46:01 +1100  largestProcess=gmail-rag
2026-03-04 16:50:14 +1100  largestProcess=gmail-rag
2026-03-04 16:57:46 +1100  largestProcess=gmail-rag
2026-03-04 17:01:57 +1100  largestProcess=gmail-rag
2026-03-04 17:03:17 +1100  largestProcess=gmail-rag
2026-03-04 17:10:42 +1100  PANIC (watchdog timeout)

Artifact 3: Quantitative memory attribution from Jetsam snapshots

| Timestamp (+1100) | Codex total GiB | gmail-rag total GiB | largestProcess |
|---|---:|---:|---|
| 2026-03-04 16:36:33 | 1.07 | 49.06 | gmail-rag |
| 2026-03-04 16:42:26 | 1.09 | 67.55 | gmail-rag |
| 2026-03-04 17:01:57 | 1.09 | 72.85 | gmail-rag |
| 2026-03-04 17:03:17 | 1.09 | 43.67 | gmail-rag |

Correction

This dataset supports severe system memory pressure + watchdog failure, but it does not prove Codex was the primary memory driver in this incident.

What the artifacts support:

• Codex was present and contributed some memory load.
• Dominant pre-panic memory footprint in this capture was gmail-rag.

I still think process-lifecycle hardening (child cleanup / process-group teardown / leak-resistant shutdown) is worth pursuing, but this specific crash should be described with the attribution above.