mirror of
https://github.com/openai/codex.git
synced 2026-04-29 02:41:12 +03:00
0d1539e74c
## Problem Ubuntu/AppArmor hosts started failing in the default Linux sandbox path after the switch to vendored/default bubblewrap in `0.115.0`. The clearest report is in [#14919](https://github.com/openai/codex/issues/14919), especially [this investigation comment](https://github.com/openai/codex/issues/14919#issuecomment-4076504751): on affected Ubuntu systems, `/usr/bin/bwrap` works, but a copied or vendored `bwrap` binary fails with errors like `bwrap: setting up uid map: Permission denied` or `bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted`. The root cause is Ubuntu's `/etc/apparmor.d/bwrap-userns-restrict` profile, which grants `userns` access specifically to `/usr/bin/bwrap`. Once Codex started using a vendored/internal bubblewrap path, that path was no longer covered by the distro AppArmor exception, so sandbox namespace setup could fail even when user namespaces were otherwise enabled and `uidmap` was installed. ## What this PR changes - prefer system `/usr/bin/bwrap` whenever it is available - keep vendored bubblewrap as the fallback when `/usr/bin/bwrap` is missing - when `/usr/bin/bwrap` is missing, surface a Codex startup warning through the app-server/TUI warning path instead of printing directly from the sandbox helper with `eprintln!` - use the same launcher decision for both the main sandbox execution path and the `/proc` preflight path - document the updated Linux bubblewrap behavior in the Linux sandbox and core READMEs ## Why this fix This still fixes the Ubuntu/AppArmor regression from [#14919](https://github.com/openai/codex/issues/14919), but it keeps the runtime rule simple and platform-agnostic: if the standard system bubblewrap is installed, use it; otherwise fall back to the vendored helper. The warning now follows that same simple rule. If Codex cannot find `/usr/bin/bwrap`, it tells the user that it is falling back to the vendored helper, and it does so through the existing startup warning plumbing that reaches the TUI and app-server instead of low-level sandbox stderr. ## Testing - `cargo test -p codex-linux-sandbox` - `cargo test -p codex-app-server --lib` - `cargo test -p codex-tui-app-server tests::embedded_app_server_start_failure_is_returned` - `cargo clippy -p codex-linux-sandbox --all-targets` - `cargo clippy -p codex-app-server --all-targets` - `cargo clippy -p codex-tui-app-server --all-targets`
71 lines
3.3 KiB
Markdown
71 lines
3.3 KiB
Markdown
# codex-core
|
|
|
|
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
|
|
|
|
## Dependencies
|
|
|
|
Note that `codex-core` makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:
|
|
|
|
### macOS
|
|
|
|
Expects `/usr/bin/sandbox-exec` to be present.
|
|
|
|
When using the workspace-write sandbox policy, the Seatbelt profile allows
|
|
writes under the configured writable roots while keeping `.git` (directory or
|
|
pointer file), the resolved `gitdir:` target, and `.codex` read-only.
|
|
|
|
Network access and filesystem read/write roots are controlled by
|
|
`SandboxPolicy`. Seatbelt consumes the resolved policy and enforces it.
|
|
|
|
Seatbelt also supports macOS permission-profile extensions layered on top of
|
|
`SandboxPolicy`:
|
|
|
|
- no extension profile provided:
|
|
keeps legacy default preferences read access (`user-preference-read`).
|
|
- extension profile provided with no `macos_preferences` grant:
|
|
does not add preferences access clauses.
|
|
- `macos_preferences = "readonly"`:
|
|
enables cfprefs read clauses and `user-preference-read`.
|
|
- `macos_preferences = "readwrite"`:
|
|
includes readonly clauses plus `user-preference-write` and cfprefs shm write
|
|
clauses.
|
|
- `macos_automation = true`:
|
|
enables broad Apple Events send permissions.
|
|
- `macos_automation = ["com.apple.Notes", ...]`:
|
|
enables Apple Events send only to listed bundle IDs.
|
|
- `macos_launch_services = true`:
|
|
enables LaunchServices lookups and open/launch operations.
|
|
- `macos_accessibility = true`:
|
|
enables `com.apple.axserver` mach lookup.
|
|
- `macos_calendar = true`:
|
|
enables `com.apple.CalendarAgent` mach lookup.
|
|
- `macos_contacts = "read_only"`:
|
|
enables Address Book read access and Contacts read services.
|
|
- `macos_contacts = "read_write"`:
|
|
includes the readonly Contacts clauses plus Address Book writes and keychain/temp helpers required for writes.
|
|
|
|
### Linux
|
|
|
|
Expects the binary containing `codex-core` to run the equivalent of `codex sandbox linux` (legacy alias: `codex debug landlock`) when `arg0` is `codex-linux-sandbox`. See the `codex-arg0` crate for details.
|
|
|
|
Legacy `SandboxPolicy` / `sandbox_mode` configs are still supported on Linux.
|
|
They can continue to use the legacy Landlock path when the split filesystem
|
|
policy is sandbox-equivalent to the legacy model after `cwd` resolution.
|
|
|
|
Split filesystem policies that need direct `FileSystemSandboxPolicy`
|
|
enforcement, such as read-only or denied carveouts under a broader writable
|
|
root, automatically route through bubblewrap. The legacy Landlock path is used
|
|
only when the split filesystem policy round-trips through the legacy
|
|
`SandboxPolicy` model without changing semantics. That includes overlapping
|
|
cases like `/repo = write`, `/repo/a = none`, `/repo/a/b = write`, where the
|
|
more specific writable child must reopen under a denied parent.
|
|
|
|
The Linux sandbox helper prefers `/usr/bin/bwrap` whenever it is available and
|
|
falls back to the vendored bubblewrap path otherwise. When `/usr/bin/bwrap` is
|
|
missing, Codex also surfaces a startup warning through its normal notification
|
|
path instead of printing directly from the sandbox helper.
|
|
|
|
### All Platforms
|
|
|
|
Expects the binary containing `codex-core` to simulate the virtual `apply_patch` CLI when `arg1` is `--codex-run-as-apply-patch`. See the `codex-arg0` crate for details.
|