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

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.