Codex can make unsafe host-system recommendations from sandbox-distorted execution context

Open 💬 2 comments Opened May 20, 2026 by markiejee

(This is a safety/product bug, not only a distro-specific CLI bug. The reproduction
happened on Linux/CachyOS, but the issue is broader: Codex should not treat sandbox/
container/AppContainer/TCC/UAC/WSL-restricted observations as host truth without
explicit verification)

Summary:
Codex may observe the user’s machine through a sandbox, container, user namespace,
virtualization layer, restricted permission context, or app security boundary, then
incorrectly treat that view as authoritative host/system truth. This can produce
false findings about filesystem state, ownership, permissions, services, devices,
networking, credentials, package integrity, boot state, or OS health.

This is not limited to one Linux distro. It likely applies across Linux
distributions and may also apply across macOS, Windows, WSL, iOS/iPadOS, Android,
and other environments where Codex runs with a restricted or virtualized execution
context.

Example reproduction:
On a Linux VM, Codex saw:

root-owned system files as uid/gid 65534 due to uid namespace mapping
global mounts such as /, /run, and /boot as read-only
/boot as inaccessible
host auth state as broken or suspicious

Codex almost recommended recovery-style actions. Later checks showed the shell was
running inside a container/user namespace, while the host system was operating
normally.

Generalized risk:
Codex can confuse sandbox artifacts with host facts, including but not limited to:

Linux:

UID/GID namespace artifacts such as root-owned files appearing as nobody/65534
read-only or bind-mounted views of /, /run, /boot, /sys, /proc, /dev
distorted output from service managers, package verification, bootloader checks,

journal access, mount checks, device checks, and permission checks

macOS:

App sandbox and TCC permission limits affecting files, keychain, camera,

microphone, calendar, contacts, automation, and full disk access

SIP, APFS snapshots, sealed system volume, and containerized app paths being

misread as host damage

launchd/service visibility differing by user/session/context

Windows:

UAC integrity levels, AppContainer, Defender-controlled folder access,

virtualization, reparse points, ACL restrictions, and per-user registry/file
virtualization

WSL/Hyper-V/container views being mistaken for the Windows host
service, driver, firewall, device, and credential-store checks reflecting a

restricted context

WSL:

Linux userspace view being mistaken for Windows host state, or Windows mount/

permission translations being mistaken for corruption

systemd, device, network, and filesystem behavior differing from native Linux

Mobile/locked-down OSes:

iOS/iPadOS/Android app sandboxing, scoped storage, permission prompts, and

unavailable system APIs being mistaken for missing/damaged user data or OS
components

Impact:
This can lead Codex to provide confident but false guidance, including risky
recovery, repair, reinstall, permission-reset, ownership-reset, bootloader,
credential, firewall, package-manager, or filesystem advice. Users may take harmful
actions based on observations that are artifacts of Codex’s execution environment.

Expected behavior:
Codex should explicitly reason about and disclose its execution context before
making host/system-level claims. Any host-global diagnostic result obtained from a
sandboxed or restricted context should be labeled provisional unless verified from a
trusted host context.