From: David Uhden Collado Subject: Re: [IMPROVEMENT] Integrate the app server daemon into devel/codex. To: kirill@korins.ky, ports@openbsd.org Date: Wed, 14 Oct 2026 00:40:00 +0000 Kirill A. Korinsky wrote: > On Tue, 13 Oct 2026 21:59:00 +0200, > David Uhden Collado 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.