On Fri, 28 Aug 2026 21:32:00 +0200, David Uhden Collado <[email protected]> wrote: > > [1 <text/plain; UTF-8 (7bit)>] > Hello, > > I'd like to propose the attached improvement to the devel/codex > pkg-readme. > > The current README only mentions that Codex may require more memory and > file descriptors and suggests increasing datasize and maxfiles limits. > The new version expands this into a more practical OpenBSD-specific > guide. > > It explains that larger Codex workloads may consume significant memory, > spawn many subprocesses, and use a large number of file descriptors, > especially when multiple agents are running in parallel. > > Rather than recommending that users raise limits globally, the updated > README suggests creating a dedicated "codex" login class in > /etc/login.conf with higher openfiles, maxproc, datasize, and stacksize > limits. > > It also documents the complete procedure: > > - adding the login class; > - rebuilding login.conf.db with cap_mkdb(8); > - assigning the class with usermod(8); > - starting a new login session so the limits actually take effect; > - checking the resulting limits with ulimit. > > The proposed values are explicitly described as starting points for > heavier workloads rather than requirements. > > The final section also makes a distinction between per-user login class > limits and system-wide kern.maxproc/kern.maxfiles limits, recommending > that the latter only be changed if they are actually the bottleneck. > > I think this is more useful than the current generic recommendation, > while keeping resource-limit changes scoped to users who actually run > Codex. > > Thank you for your time and consideration. > > Best regards, > David. > [2 codex-README.patch <text/x-patch; UTF-8 (base64)>] > Index: pkg/README > =================================================================== > RCS file: /cvs/ports/devel/codex/pkg/README,v > diff -u -p -u -r1.2 README > --- pkg/README 24 Aug 2026 16:39:57 -0000 1.2 > +++ pkg/README 28 Aug 2026 19:26:48 -0000 > @@ -14,9 +14,60 @@ one you should add into ~/.codex/config. > base_url = "http://127.0.0.1:8080/v1"; > wire_api = "responses" > > -${PKGSTEM} uses a lot of memory, it starts with 256Mb per agent/worker > -thread, and you may need to bump your limits (`ulimit -d`) or raise > -datasize limit in used login class.. > +Resource limits > > -Also, ${PKGSTEM} may use a lot of open files, you may need to raise both > -the system-wide maxfiles and used login class limits. > +Codex can spawn multiple subprocesses (shell, ripgrep, git, python, > +etc.), run several agents in parallel, and use a significant number of > +file descriptors and a lot of memory when working on large > +repositories. On current OpenBSD, the default login class limits > +datasize to 1536M, maxproc to 128 and openfiles to 512. Small sessions > +fit within these limits, but large or highly parallel Codex workloads > +may hit them. > + > +Recommended login class > + > +If Codex fails to spawn processes, runs out of memory, or reports > +"too many open files", consider creating a dedicated login class > +instead of raising the limits of every user. Add this to > +/etc/login.conf: > + > +codex:\ > + :openfiles-cur=1024:\ > + :openfiles-max=2048:\ > + :maxproc-cur=512:\ > + :maxproc-max=1024:\ > + :datasize-cur=8G:\ > + :datasize-max=16G:\ > + :stacksize-cur=8M:\ > + :stacksize-max=16M:\ > + :tc=default: > + > +Rebuild the login class database so the change takes effect: > + > + # cap_mkdb /etc/login.conf > + > +Apply the class > + > +Assign the class to the user who runs Codex: > + > + # usermod -L codex <user> > +
I not sure that creating a dedicated login class and associeted it with user facing tool is sane idea. Also, why you suggest to use 1024/2048 and 8G/16G? What happened with users who has just 16Gb ram? > +Start a new login session afterwards: log out and log in again so > +that the new limits are applied. Merely starting a new shell does not > +update the login class of the current session. > + > +Verify > + > +Check the effective limits from the user's session: > + > + $ ulimit -a > + > +The relevant entries are nofiles (openfiles), processes (maxproc) and > +data (datasize). In the default ksh you can also query them > +individually with `ulimit -n`, `ulimit -p` and `ulimit -d`. > + > +Increase these values only as needed; the values above are starting > +points for heavier workloads. Login-class limits are preferable to > +raising system-wide kernel limits; consider kern.maxproc and > +kern.maxfiles only if the kernel limits turn out to be the actual > +bottleneck after raising the login class. -- wbr, Kirill
