codex - 💡(How to fix) Fix Sandboxed commands print "Failed to create stream fd" on Ubuntu 26.04

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Code Example

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

---

true

---

systemd-cat true

---

Failed to create stream fd: Operation not permitted

---

bwrap --ro-bind / / true
RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Sandboxed commands print "Failed to create stream fd" on Ubuntu 26.04