Opportunity: make host-faithful local use a first-class Codex workflow

What variant of Codex are you using?

CLI

What feature would you like to see?

Codex CLI already has the technical building blocks for host-faithful local execution: users can combine sandbox_mode = "danger-full-access" with approval_policy = "on-request" in ~/.codex/config.toml or a named profile. That means this is not really a missing-capability request. It feels more like a productization opportunity: turning an already-possible setup into a clearer, more intentional workflow for people using Codex directly on trusted developer machines.

Right now, the product experience understandably centers the sandboxed workflow, which makes sense as a safe default. But there seems to be a meaningful second audience: users who want Codex to operate directly in their real local environment while still keeping approvals on and building trust gradually. For those users, the current experience can feel more like “you can do this if you really want to” than “this is a supported way to use Codex.”

Potential improvements:

• a clearly named local / trusted-workstation preset or onboarding choice
• docs that frame sandboxed and host-faithful local usage as two valid workflows with different tradeoffs
• startup UX that helps users choose the right mode for their environment
• a more cumulative approval model for local use, such as per-repo or narrowly scoped persistent approvals, so users can move toward a “capable but not dangerous” baseline over time

This seems like a good opportunity to improve clarity and adoption for external users without changing the existing sandbox-first defaults. The underlying capability is already there; the main gap is making the intended local workflow easier to discover, easier to trust, and easier to use confidently.

Making this a clearly named, endorsed first-class workflow would also help keep it healthy over time, rather than leaving it as an escape hatch that may drift as the sandboxed path continues to evolve.

Additional information

A few concrete examples from the last week:

• The trust model feels weak for interactive local work: per-repo or cumulative approvals are not really manageable from within the Codex app itself, which makes them much less useful for exploratory “figure it out as we go” workflows than they could be.
• In local cluster and LAN-host workflows, sandboxed networking and execution context added ambiguity on top of already-complicated real infrastructure issues, making it harder to tell whether a failure belonged to the host, the cluster, or the wrapper.
• On macOS workstation tasks, even normal local development workflows like go test ./... became harder to reason about because freshly built local binaries started triggering repeated permission prompts after an OS/IT-driven update, and the mismatch between Codex’s execution context and my real shell made it harder to separate host-policy problems from tool-wrapper problems.

Taken together, this has felt less like an isolated edge case and more like a recurring pattern: the host-faithful mode exists, but the sandbox-first experience is the path that keeps getting exercised and accumulating the sharp edges.