OpenBSD Sandbox Support

[donpellegrino]

What variant of Codex are you using?

CLI

What feature would you like to see?

It would be useful to have sandbox support on OpenBSD.

Additional information

Issue #12338 references OpenBSD support as a new feature generally. There is a Port of Codex (https://marc.info/?l=openbsd-ports&m=176853999431595&w=2, https://cvsweb.openbsd.org/ports/devel/codex?sort=File) to OpenBSD, however it does not include a sandbox implementation. I have started some proof-of-concept work on an implementation of a sandbox on OpenBSD (DeciSym/openbsd-port-codex#1).

[Mahkhmood9]

With all the respect , for openbsd usage ,

the codex openbsd , is an experimental port

the https://marc.info/?l=openbsd-ports&m=176853999431595&w=2
mention a local port of codex , to use lllmccp

and I see you forked the project , and made beautiful expirementation
and
https://github.com/openai/codex/blob/35aaa5d9/codex-rs/linux-sandbox/src/linux_run_main.rs

which take use of
https://docs.rs/landlock/latest/landlock/

and
https://github.com/openai/codex/blob/35aaa5d9fcb606fb6f27dd5747ecab3f4ba0c07e/codex-rs/sandboxing/src/seatbelt_tests.rs

seatbelt for macintosh

and for openbsd abd freebsd
there isnt something clear beside
Capsicum (freebsd)

OpenBSD pledge(2) manual (c++ function for sandboxing? / kernel feature of openbsd) https://man.openbsd.org/pledge.2
OpenBSD unveil(2) manual(cc++ function for sandboxing? / kernel feature of openbsd https://man.openbsd.org/unveil.2)
and FreeBSD Jail? which I dont understand really, Its like using a VM or docker ... when sandboxing, is a different feel

as per AIX (which I use to love too doesnt appear to have any sandboxing beside ) -- so should use now port AIX to have codex user expirence cli? like you can maybe enjoy AIX , because you found a POWER9 ibm second hand server,

---

after using some llm , I found this paper,
which says pledge and unveil , is a simular capability

https://arxiv.org/pdf/2509.18548
(maybe shed insights on bsd sandboxing , I couldnt find a https://docs.rs/landlock/latest/landlock/ rust-landlock project for openbsd)

and its not a magic library for openai they can use for sandboxing in rust, or for anyone who tries to make a freebsd/openbsd port ---- personally I think its correct only to support linux/windows/macos , because of rust limitation? KERNEL API limitation or whatever?

[Mahkhmood9]

refrenching
https://github.com/landlock-lsm/rust-landlock/tree/main/src
landlock(linux, and used by codex- openai)

--
other approch I see , which is running the coding-client within a jail some how
https://wal.sh/research/2026-agent-isolation-freebsd-jails/index.html

edit 3#
https://github.com/i80and/pledge-rs/blob/master/src/promise.rs#L48
there is a pledge-rd which was last maintained 6 years ago

so never the less , sandboxing might be possible , and no need to write a pledge library for rust

[donpellegrino]

@Mahkhmood9 - thanks for the references. My initial approach is to begin with the Codex configuration and policy semantics that Codex advertises to its users (e.g.,

codex/codex-rs/app-server-protocol/src/protocol/v2/permissions.rs

Line 593 in 178c3d3

pub enum SandboxPolicy {

). The Codex policies are supported with differing mechanisms by the underlying OS-specific sandboxing implementations. My initial proof-of-concept needs to identify what can and can't actually be enforced by OpenBSD so that users can have a comprehensible and auditable relationship between the Codex policy semantics and the the controls. I am starting with unveil(), pledge(), and pledge() with execpromises as key components of an implementation.

[Mahkhmood9]

@Mahkhmood9 - thanks for the references. My initial approach is to begin with the Codex configuration and policy semantics that Codex advertises to its users (e.g.,

codex/codex-rs/app-server-protocol/src/protocol/v2/permissions.rs

Line 593 in 178c3d3

pub enum SandboxPolicy {
). The Codex policies are supported with differing mechanisms by the underlying OS-specific sandboxing implementations. My
initial proof-of-concept needs to identify what can and can't actually be enforced by OpenBSD so that users can have a comprehensible and auditable relationship between the Codex policy semantics and the the controls. I am starting with unveil(), pledge(), and pledge() with execpromises as key components of an implementation.

worth mentioning, PLEDGE or UNVEIL , arent the same thing as BWRAP(Linux, and in the codex-rs project)
https://man.openbsd.org/pledge.2
**pledge is not sandboxing / container **

I want to mention
https://github.com/samuelkarp/runj

which was mention in opencontainers/runc#1501

https://github.com/containers/bubblewrap
(openai codex imports this vendor https://github.com/openai/codex/tree/main/codex-rs/vendor/bubblewrap)

mention
binctr,
bottom line
https://github.com/dlrobertson/capsicum-rs

https://man.freebsd.org/cgi/man.cgi?query=capsicum

**anything practical Is using capsicum , which is for FreeBSD

Codex-rs support both bwrap and landlock** as per the linux refrence

https://github.com/openai/codex/blob/main/codex-rs/linux-sandbox/src/linux_run_main_tests.rs

https://man.freebsd.org/cgi/man.cgi?query=capsicum

capsicum is the onlything close to bwrap/landlock

unveil/pledge is different its like a Premission based thing

---

as per XNU / DARWIN / MACOS
it actually appears to be simular to Pledge
https://manpagez.com/man/3/sandbox_init/
https://manpagez.com/man/7/sandbox/

https://github.com/openai/codex/blob/main/codex-rs/sandboxing/src/seatbelt.rs

anyways in my eyes, linux is the winner here,
but I am not a kernel developer! never been! you likley dont even want sandbox in openbsd, and remove this sandboxing part ---
let along with gpt 5.5 , being mostly training on Linux shell and MacOs shell... But its really and issue , since macos/xnu/darwin as a very simular feel to Bsd systems , in terms of usage,

also even in linux 90% of your linux distros use linux-gnu which is solid (and I HATE POSIX haha) and using Busybox would give issues , with a coding agent

1. The "Gnu-ism" vs. **BusyBox** Conflict
Most coding agents generate shell commands assuming the GNU Coreutils suite. BusyBox, however, uses a single binary to provide stripped-down versions of these tools.

Flag Incompatibility: Agents often use advanced flags (e.g., sed -i behavior differences or grep --perl-regexp). BusyBox applets often support only a fraction of these flags, leading to "invalid option" errors.

Missing Tools: Standard agents might try to use bash specific syntax (like [[ ... ]] or arrays), but many BusyBox environments only provide ash or sh, which are strictly POSIX-compliant and lack those features.

{{not that coding agents use too many commands, but busybox is an example for why not bsd,, yet macos is a thing , so I assume it can figure to use macos-like commands and hygine}}

[Mahkhmood9]

@Mahkhmood9 - thanks for the references. My initial approach is to begin with the Codex configuration and policy semantics that Codex advertises to its users (e.g.,

codex/codex-rs/app-server-protocol/src/protocol/v2/permissions.rs

Line 593 in 178c3d3

pub enum SandboxPolicy {
). The Codex policies are supported with differing mechanisms by the underlying OS-specific sandboxing implementations. My initial proof-of-concept needs to identify what can and can't actually be enforced by OpenBSD so that users can have a comprehensible and auditable relationship between the Codex policy semantics and the the controls. I am starting with unveil(), pledge(), and pledge() with execpromises as key components of an implementation.

You likely want to bypass sandboxing functionally (have it not use it all ) for openbsd, and see what else you need to modify --- plus the rust ecosystem is really fun , I am attempting porting codex into freebsd now aswell

[donpellegrino]

https://github.com/DeciSym/codex/tree/openbsd-sandbox has the working proof-of-concept implementing an OpenBSD sandbox enforcing the Codex sandbox policy with all available tests passing.

[Mahkhmood9]

https://github.com/DeciSym/codex/tree/openbsd-sandbox has the working proof-of-concept implementing an OpenBSD sandbox enforcing the Codex sandbox policy with all available tests passing.

I have also toyed with it , I got it to run FreeBSD (and there is no other port for it for FreeBSD??????), its pretty cool --- I toyed with it ... also toyed and stripped down ,, its pretty solid ... but I suffer from "Developer Pride Syndrom" when a human like me does a bad quality job,, but so proud he got it barely working -- yet ship a poorly made product (also for example why open source project have so many issues... and why Linux Foundation donation ,,, drive actually good coding practices that comes from Enterpise and structism ---- being from Kyrgyzstan... and reminder I was at late 20s when the USSR started falling --- so I think about economy a lot --- and structed and oragnism)

Thats cool, but also I think its shows how great linux has become ---- I dont have proofs but I am pretty sure busybox (non gnu) such as Alpine linux , can be very problematic with Codex/ gpt due the nature of GNU . Alltho I am very proud to have a contirbuted some code many many years ago to gnu...
also rises another issue , like how coding agents do not fully ultalize , you grep or whatever , when they can. and they do it better in recent months...

GIT for me is much harder than SVN or CVS, For me atleast.. but it has its place? its like GIT the moment you use it , its better (unrelated, but its a comment as about Busybox)

OpenBSD is a toy project , many Linux developers of the 90s end up in microsoft for example.. Powershell can be decent, and it is useful, but its not perfect... and if OpenBSD is much more stable , than what I seen (when I tried to install it barebone , it crashed because of kernel internet drivers? I had to modify openbsd ? how network drivers causes the machine to crash?) ,, OpenBSD has gotten better, because its the same developers who also in the linux kernel developent sphere.

Ai system in the future should adopt , to learn more paramers .... Because tool have complexity... Or if they dont , and if they dont ... it prove why we human dont use it (the gnu vs busybox debate).... a lot of systems like Alpine Linux uses busybox ```ls, grep, sed, or awk) are "stripped down" to save space```` ... in the same way its pretty funny, even us humans have like "system prompts" Oh I now should act like I am going to use MacOS.. going to use this best practices))
Alpine uses Ash (via BusyBox) yet it coding agents now need to adopt magically ,,, I also wonder how those Linux Eval , compare on exotic machines such as OPENBSD

Thanks))

Edit:: I marked this comment as irrlevant , because its also iirelvant to the discussion PLEDGE, UNVEILE and Sandboxing such as Landlock ,,, systemd nspawn,, docker,,, sandboxing,,, freebsd-jails (the ones on XNU --- and the whatever reason its a research topic ,,, and a Sales pitch into selling another feature to the linux kernel)