Why Cue still uses AppContainer after Codex rejected it for Windows agents

OpenAI’s write-up on enabling Codex on Windows is blunt: AppContainer is the wrong shape for an open-ended coding agent.

That’s a serious claim. Cue — a Windows 11 desktop coding agent that does run Codex CLI under capability-zero AppContainer — has to answer it without marketing fog.

This post is that answer: what Codex optimized for, what Cue deliberately narrowed, and where the honest limits still are.

Repo: https://github.com/zenovis2-create/cue
Demo (mp4): https://github.com/zenovis2-create/cue/blob/main/docs/assets/cue-demo-en.mp4
Product Hunt: https://www.producthunt.com/products/cue-24?launch=cue-bea6eb17-4a05-470a-b95e-329e9a81ef8d

What Codex needed (and why AppContainer lost)

From OpenAI’s public Windows sandbox notes (and independent summaries of those primitives):

• A coding agent doesn’t look like a packaged app with a fixed, known-up-front capability set.
• It drives open-ended workflows: shells, Git, interpreters, package managers, build tools — binaries chosen at runtime.
• AppContainer is a capability-based model built for apps that can declare access ahead of time.
• Firewall rules tied to a restricted-token identity also don’t cleanly follow child processes the way agent workloads need.

So Codex moved to a different composition (synthetic SIDs, write-restricted tokens, dedicated local principals, etc.) — optimized for “operate like a developer” with a broader workspace story.

That critique is real. Cue does not pretend otherwise.

What Cue is optimizing for instead

Cue is not trying to win “most open-ended agent on Windows.”

Cue’s bet is the other failure mode people feel day to day:

• YOLO defaults — wide desktop session, hard to trust
• Endless approval loops — safe-feeling, exhausting

Cue’s shape:

1. Natural-language goals via Codex CLI
2. Only inside approved worktrees
3. Capability-zero AppContainer isolation
4. An execution envelope that does not expand after approval
5. Credentials not written into the UI or a ledger
6. MIT, Windows 11 + Electron today

In other words: Cue treats AppContainer’s “narrowness” as a feature of the product contract, not a bug to paper over.

If the agent shouldn’t be a free-roaming developer identity on the whole machine, then a boundary that wants a declared envelope is aligned with the UX: approve the worktree once; don’t silently widen it.

AppContainer vs “sandbox theater”

“Sandbox” on the desktop often means hope plus a checkbox.

Cue’s claim is smaller and more checkable:

• Which folders were approved?
• Did the envelope grow after approval? (It shouldn’t.)
• Are credentials being journaled into the product UI/ledger? (They shouldn’t.)

That still is not a proof of “no bypass ever.” AppContainer is an OS boundary with tradeoffs. If you can show a concrete bypass path, open a GitHub issue — that’s higher signal than a launch-day upvote.

UAC / elevated friction (honest)

Windows agent setups hit UAC / elevated friction. Cue does not advertise that away.

Depending on what the agent needs to run, elevated prompts can still appear. The product focus is the approved-worktree + AppContainer envelope for Codex CLI — not a promise that Windows will stop asking hard questions.

How to read the Codex rejection next to Cue

Question	Codex Windows sandbox direction	Cue
Workload shape	Open-ended “developer-like” agent	Envelope-first coding agent
AppContainer	Rejected as wrong shape for that workload	Chosen because Cue’s workload is declared folders
Success metric	Capable agent under a custom Windows composition	Readable boundaries; stars + critical issues
Mac/Linux	Separate story	Not claimed (Win11 only now)

Different objective functions. Same underlying tension: isolation primitives must match the agent’s freedom budget.

What feedback actually helps

Useful:

• Repro: “I approved X; the agent reached Y”
• Threat notes on envelope expansion or credential handling
• Comparisons to other Windows isolation stacks you’ve shipped

Less useful:

• “Just trust the model”
• Name collisions with unrelated “Cue” products (this one is zenovis2-create/cue; not Maestro Cue)

Links

• GitHub: https://github.com/zenovis2-create/cue
• Product Hunt launch: https://www.producthunt.com/products/cue-24?launch=cue-bea6eb17-4a05-470a-b95e-329e9a81ef8d

If you’ve shipped sandboxed desktop tooling and think AppContainer is still the wrong primitive even for an approved-worktree agent, say why — ideally with a failure mode, not a vibe.