Kirill A. Korinsky wrote:
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.
Hi,
The intention behind the dedicated login class is precisely to avoid
changing the limits globally.
Codex is somewhat unusual for a user-facing application because it can
behave more like a development workload: it can launch multiple agents,
shells, git, ripgrep, compilers, Python processes, etc. A sufficiently
large or parallel session can therefore hit several of the default
limits at the same time.
Using a separate login class gives users who actually need higher
limits an explicit and reversible way of getting them, without raising
the default class or system-wide limits for everybody.
It is not intended to be required for every Codex user. The README says
to use it if Codex actually starts hitting process, memory, or file
descriptor limits, and also says that the values are only starting
points which should be increased as needed.
Regarding 8G/16G, those values are limits, not reservations. Setting:
datasize-max=16G
does not allocate or reserve 16 GB of RAM for Codex. It only allows a
process to grow up to that limit if memory is actually available.
Someone with 16 GB of RAM will not suddenly lose 16 GB to Codex simply
because that limit exists.
I chose 8G/16G mainly to leave enough headroom for unusually large
workloads while making the distinction between the normal and hard
limits clear. I would be fine with using more conservative example
values if those numbers look excessive, or making the wording even more
explicit that they should be adjusted according to the machine.
The same applies to openfiles and maxproc. 1024/2048 file descriptors
are not consumed merely because those limits are configured, and a
maxproc limit of 1024 does not cause 1024 processes to be created. They
simply prevent the login class from becoming the first bottleneck during
large parallel workloads.
I still prefer documenting a login-class solution rather than telling
users to immediately increase kern.maxfiles or kern.maxproc. The latter
changes affect the entire system, whereas login.conf lets the higher
limits be restricted to the account where they are actually needed.
Perhaps the README could make this distinction clearer and explicitly
say that users on smaller systems should choose lower values, but I
think documenting the login-class approach itself is useful.
Thanks,
David.
