Kirill A. Korinsky wrote:
> On Tue, 13 Oct 2026 21:59:00 +0200,
> David Uhden Collado <daviduhden@gmail.com> 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.