›_ Codex Issues
Codex Issues / #22367

Sandboxed commands print "Failed to create stream fd" on Ubuntu 26.04

Open 💬 2 comments Opened May 12, 2026 by jereviikari

On Ubuntu 26.04, Codex sandboxed command execution succeeds but prints repeated
systemd-cat/journald errors before command output:

Failed to create stream fd: Operation not permitted
Failed to create stream fd: Operation not permitted
Failed to create stream fd: Operation not permitted

Environment

  • Ubuntu 26.04 LTS resolute
  • bubblewrap 0.11.1-1
  • apparmor 5.0.0~beta1-0ubuntu7
  • /etc/apparmor.d/bwrap-userns-restrict is present and owned by the apparmor package
  • aa-status shows bwrap and unpriv_bwrap loaded in enforce mode

Reproduction

Run a simple sandboxed command through Codex, for example from /tmp or /home/user:

true

The command exits successfully, but stderr contains the repeated warning.

A more direct test shows the likely source:

systemd-cat true

Inside the Codex sandbox this fails with:

Failed to create stream fd: Operation not permitted

Outside the Codex sandbox, systemd-cat true succeeds.

Also observed:

bwrap --ro-bind / / true

This succeeds outside the Codex sandbox. Running nested bwrap inside the Codex sandbox fails, which may be expected due to confinement/no_new_privs.

Expected Behavior

Successful sandboxed commands should not emit journald/systemd-cat stream setup
errors. If journald stream setup is unavailable inside the sandbox, Codex should
avoid that path, make it optional, or silently fall back.

Actual Behavior

Every successful sandboxed command prints the warning three times before command
output. This makes command output noisy and may confuse tooling that consumes
stderr.

Notes

This does not appear to be the old Ubuntu 24.04 missing AppArmor profile issue.
On Ubuntu 26.04 the bwrap-userns-restrict profile is already shipped at
/etc/apparmor.d/bwrap-userns-restrict by the base apparmor package, and
aa-status reports the relevant profiles as loaded.

View original on GitHub ↗

2 Comments

luchasarie · 1 month ago

+1 here, confirmed on ubuntu 26.04 and codex ver 0.144

joeloverbeck · 1 month ago

I traced this to a login-shell startup interaction with Ubuntu's im-config, rather than a failure in the command being run.

Confirmed environment

  • Codex CLI 0.145.0
  • Ubuntu 26.04 Resolute
  • bash
  • GNOME/Wayland
  • im-config 0.62

Minimal control

Inside the Codex restricted sandbox:

bash -c /bin/true

is clean, while:

bash -lc /bin/true

prints the warning exactly three times and still exits 0. This was deterministic across repeated runs.

Causal chain

  1. A login shell sources /etc/profile.d/im-config_wayland.sh.
  2. That sources /usr/share/im-config/initializer.
  3. In Ubuntu's installed im-config 0.62, the initializer selects /usr/bin/systemd-cat for logging.
  4. It defaults IM_CONFIG_VERBOSE="false", but logger_debug() tests only whether that string is nonempty. Therefore three debug paths invoke systemd-cat even though verbosity is nominally false.
  5. Each systemd-cat tries to connect to /run/systemd/journal/stdout.

I traced both paths:

  • Outside the sandbox, all three connect(AF_UNIX, "/run/systemd/journal/stdout", ...) calls return 0.
  • Through Codex's actual managed sandbox helper with network: "restricted", the same three calls return EPERM; /bin/true then executes and exits 0.

So the sandbox denial itself looks correct. The stderr message is fallout from a host login-profile script attempting journald access during sandboxed shell initialization.

Upstream status

The newer Debian im-config 1.1 logger uses numeric verbosity and only emits debug logging at level 2, so this particular "false"/nonempty bug is no longer present:

https://salsa.debian.org/input-method-team/im-config/-/blob/debian/1.1/share/logger_function

Ubuntu 26.04 currently still provides 0.62 on this machine.

Codex-side value

The primary bug is in im-config, but Codex can amplify it when login-shell initialization is run repeatedly (especially across agent/subagent command sessions). The result is harmless to the target command but adds three misleading stderr lines to many commands and can obscure real failures.

Potential Codex-side mitigations could be to reuse captured shell environments more consistently, avoid a login shell when the environment is already initialized, or expose/document a global non-login-shell default. I would avoid broadly suppressing shell-initialization stderr, since that could hide legitimate startup errors.