On Tue, 20 Oct 2026 14:54:00 +0200, David Uhden Collado <[email protected]> wrote: > > Kirill A. Korinsky wrote: > > On Tue, 20 Oct 2026 08:57:00 +0200, > > David Uhden Collado <[email protected]> wrote: > >> > >> OpenBSD does not currently provide a supported Codex sandbox backend. > >> pledge/unveil cannot reliably enforce these restrictions across > >> arbitrary subprocesses created through execve. > >> > >> The first patch rejects managed sandbox profiles during configuration > >> and session creation. > >> > >> The second rejects unsupported restrictions at command execution, > >> including managed network policies that cannot be enforced by a > >> proxy alone. > >> > >> Both are necessary to cover the different execution paths. > >> > >> Explicit danger-full-access execution remains available, as does > >> the option of running Codex inside external isolation. > >> > > > > I had re-read your explanation and diffs a few times and I still does not > > understand that actually have you suggested. > > > > Can you stop using your LLM and write with extreamly simple sentence that > > you did and why? > > > > Codex uses its sandbox by default, but on OpenBSD the sandbox doesn't > work at all. In other words, it provides no actual isolation. Disabling > it explicitly prevents users from being misled into thinking they're > protected when they're not, and makes it clear that they need to use > something like --yolo to run Codex without sandbox restrictions on > OpenBSD.
Ok, when I understand it the right way. Your patches really does that just start codex... ends with fails and suggestion please run it as codex --allowd-dangerous-things I think it is not user friendly at all to ask users to add new args to all their commands. -- wbr, Kirill
