Kirill A. Korinsky wrote:
On Tue, 13 Oct 2026 21:59:00 +0200,
David Uhden Collado <[email protected]> wrote:
You're right. The previous diff included more than the daemon
integration, and I should have made that clearer. Sorry for the
confusion.
You did it again.
I don't think there is much to explain. I've added comments to the
patches explaining what each one does. I've also added comments to
patches I didn't modify so their purpose is documented as well. It just
works.
If you expect something carefully maintained by humans from OpenAI,
you're out of your mind. These people have LLMs working autonomously to
improve their services, with one or two people reviewing the results and
giving the green light before a new version gets released. The level of
automation they've achieved is incredible.
OpenAI has decided that Codex should have a daemon, and most Codex users
are going to expect the OpenBSD port to support that daemon too.
I've attached a revised diff against the current CVS tree, including the
previously missing patch files.
The daemon integration itself is relatively small. It reuses the
existing Codex executable as the app-server daemon, installs it with the
required package manifest under libexec/codex, and makes the daemon
resolver use that executable instead of downloading or copying another
one into ~/.codex/packages.
The existing upstream process management, Unix sockets, IPC, and
start/stop/restart functionality remain unchanged. Only internal
installation and self-update mechanisms are disabled, since pkg_add owns
the executable.
Why do we need that daemon on the first place?
I not sure that this is sane wrokflow:
+ codex app-server daemon start
+ codex app-server daemon version
+ codex app-server daemon restart
+ codex app-server daemon stop
What a use case do you have for that daemon?
The actual use case is the persistent app-server used by remote clients,
including desktop/mobile applications and Codex instances accessed over
SSH. It allows clients to connect to a running server and share sessions
without tying its lifetime to a particular terminal.
I want the existing upstream functionality to work with the binary
installed by the OpenBSD port, with lifecycle management remaining
optional and package updates handled exclusively by pkg_add/pkg_delete.
The official documentation for the Codex daemon is available in the
OpenAI repository:
https://github.com/openai/codex/blob/main/codex-rs/app-server-daemon/README.md
- Enable OpenBSD support in the WASM interpreter platform checks.
- Use MAP_STACK for the usable WASM stack region while preserving its
guard pages.
Does codex use wasm? really?
Codex may not currently use WASM directly, but that does not mean it
won't use it in the future.
Chromium already carries these OpenBSD-specific V8 patches, so I don't
see anything wrong with synchronizing the relevant ones with the Codex
port. Both projects use V8, and keeping the platform-specific fixes
consistent seems more reasonable than maintaining divergent implementations.
