Summary
I'm hitting intermittent Too many open files errors in Codex Monitor on macOS.
This does not look like just a random local spike. Codex Monitor's normal workload seems to keep a meaningful number of file descriptors open across:
codex-monitor- child
codex app-server
WebKit.WebContent
On my machine the soft limit is low:
ulimit -n
256
launchctl limit maxfiles
maxfiles 256 unlimited
With 5 workspaces configured, I sampled a live session and saw roughly:
codex-monitor: ~104-105 FDscodex app-server: ~94-95 FDsWebKit.WebContent: ~59 FDs
I did not prove a monotonic FD leak in a short sample, so this may be more of a headroom / scaling issue under normal session management than a continuously growing leak.
Closing idle sessions or workspaces may reduce pressure temporarily, but because session management is the core job of the app, I think normal or mostly-idle usage should stay well below the point where Too many open files is possible.
Version: 0.7.66
There also wasn't much useful local logging to show which process actually crosses the limit. If useful, I can provide lsof snapshots and a longer sampling run.
Summary
I'm hitting intermittent
Too many open fileserrors in Codex Monitor on macOS.This does not look like just a random local spike. Codex Monitor's normal workload seems to keep a meaningful number of file descriptors open across:
codex-monitorcodex app-serverWebKit.WebContentOn my machine the soft limit is low:
ulimit -n 256 launchctl limit maxfiles maxfiles 256 unlimitedWith 5 workspaces configured, I sampled a live session and saw roughly:
codex-monitor: ~104-105 FDscodex app-server: ~94-95 FDsWebKit.WebContent: ~59 FDsI did not prove a monotonic FD leak in a short sample, so this may be more of a headroom / scaling issue under normal session management than a continuously growing leak.
Closing idle sessions or workspaces may reduce pressure temporarily, but because session management is the core job of the app, I think normal or mostly-idle usage should stay well below the point where
Too many open filesis possible.Version:
0.7.66There also wasn't much useful local logging to show which process actually crosses the limit. If useful, I can provide
lsofsnapshots and a longer sampling run.