Mike Larkin wrote:
On Tue, Oct 13, 2026 at 07:59:00PM +0000, David Uhden Collado wrote:
Kirill A. Korinsky wrote:
On Tue, 13 Oct 2026 20:42:00 +0200,
David Uhden Collado <[email protected]> wrote:
Please find attached a patch proposing proper integration of the Codex
app-server daemon with the OpenBSD package system.
The port already includes the daemon functionality, but upstream
normally expects a complete standalone installation and may try to
install another Codex executable under ~/.codex/packages. This is
unsuitable for a package managed by pkg_add.
The proposed changes address this without disabling the daemon or
rewriting its lifecycle management.
Sorry, you tried to ship way more than only this changes.
You had touched many patches and reformat port's Makefile.
[2 codex-0.162.1p0.diff <text/x-patch; UTF-8 (base64)>]
? devel/codex/files
? devel/codex/patches/patch-codex-rs_app-server-daemon_src_backend_pid_rs
? devel/codex/patches/patch-codex-rs_app-server-daemon_src_lib_rs
? devel/codex/patches/patch-codex-rs_app-server-daemon_src_managed_install_rs
? devel/codex/patches/patch-codex-rs_app-server-daemon_src_prepare_install_rs
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_build_config_clang_clang_gni
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_build_detect_host_arch_py
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_AddressSpace_hpp
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_EHHeaderParser_hpp
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_third_party_libunwind_src_src_UnwindCursor_hpp
? devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_v8_gni_v8_gni
?
devel/codex/patches/patch-codex-rs_modcargo-crates_v8-150_4_0_v8_src_wasm_stacks_cc
? devel/codex/patches/patch-codex-rs_tui_src_app_daemon_menu_rs
I thunk you also forgot quite a few patches.
Can you resend your diff to minimal version which adds support of that codex
daemon?
Hello Kirill,
You're right. The previous diff included more than the daemon integration,
and I should have made that clearer. Sorry for the confusion.
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.
I also included some V8 portability improvements. These are independent of
the daemon integration, but I think they are worth considering because Codex
builds its own V8 150.4.0 and uses it for code-mode functionality.
Several changes are adapted from the OpenBSD www/chromium port patches:
- Prevent Linux-specific Clang module configuration from being enabled on
BSD.
- Correct OpenBSD arm64 host architecture detection.
- Improve libunwind handling of DW_EH_PE_omit and reuse cached unwind
sections.
- Enable OpenBSD support in the WASM interpreter platform checks.
- Use MAP_STACK for the usable WASM stack region while preserving its guard
pages.
These changes address OpenBSD-specific portability and runtime behavior
rather than daemon management. Keeping the relevant V8 fixes consistent with
Chromium should also make future updates easier to maintain.
Thanks,
David.
the right way to do this is to get this work upstreamed rather than keep
2500+ lines of patches locally. someone is going to need to make sure that these
thousands of lines of diffs keep working when upstream makes changes, and you
yourself have pointed out that the churn there is incredible. this is going
to add a ton of work moving forward for whoever is the maintainer.
you made one specific thing work for this specific version only. it's gonna
fall apart fast and we're gonna end up with thousand line diffs that patch
other thousand line diffs. but if you take the time to land this upstream then
we stand a better chance of making this continue to work.
The upstream Codex repository maintained by OpenAI restricts pull
requests to project collaborators and does not accept external code
contributions.
On the other hand, additional patches would still be needed to enable
Codex's currently disabled sandbox on OpenBSD and integrate it with the
operating system's native pledge and unveil security mechanisms.
