DEV Community: 윤대한

Describe Review Approve Inspect: A Coding Agent Loop Built for Control

윤대한 — Thu, 10 Sep 2026 08:14:37 +0000

Most local coding agents force a false choice: YOLO the desktop, or approve every tool call until you give up.

Cue is built for a third path. It is a Windows 11 Electron coding agent (MIT) that uses Codex CLI for the model path on the host, runs workspace actions under AppContainer workers, and freezes a human-readable execution envelope before anything mutates your files. You describe a goal, review the scope, approve once, then inspect a ledger — or hit Stop.

This post is about that control loop. If you want the sandbox-primitive deep dive (why AppContainer is Cue’s floor), that lives in Day1 — one link at the end. Here we stay on what using it feels like.

GitHub: https://github.com/zenovis2-create/cue
Demo (34s): https://github.com/zenovis2-create/cue/blob/main/docs/assets/cue-demo-en.mp4

The false choice — YOLO desktop vs approval fatigue

Two failure modes dominate desktop agents today.

YOLO desktop. The agent gets a wide trust surface because “real developer work” needs shells, helpers, caches, and whatever the next step invents. You move fast until something lands outside the folder you thought you meant. The product rarely shows a frozen boundary you can point at later.

Approval fatigue. The other extreme asks you to click through every tool, every path, every spawn. It feels safer for an afternoon, then you start auto-approving because the friction is the product. Control collapses into ritual.

Neither mode is “wrong” for every threat model. But both leave a gap for people who want one human decision that actually bounds the run — not unlimited trust, and not infinite micro-prompts.

Cue does not claim to “solve agent security forever.” It claims a narrower product contract: freeze the envelope before workers run, keep mutation inside the approved worktree, and make outcomes inspectable.

The four-step loop

Cue’s loop is deliberately short:

Describe — Enter a natural-language coding goal and pick a workspace (plus an autonomy level).
Review — Read a three-line scope summary and the execution envelope: where it can work, what it may do, what it leaves untouched.
Approve — Or cancel. No approval, no task execution.
Inspect — Watch ledger-backed progress and a result of completed, blocked, or human-required. Stop anytime.

Fail-closed matters as much as the happy path. If you cancel at the workspace picker, execution does not start. Cue retains cancel evidence under README Verification (P12 cancel) for that fail-closed behavior — this post will not reprint those tables.

The security story is not “trust the model, then restrict whatever it tried.” It is “freeze the envelope, then run only inside it.”

What “execution envelope” means here

An execution envelope, in Cue, is the human-approved scope for a coding run: the worktree and allowed actions frozen before workspace workers start. After approval, the envelope does not expand.

That definition is the product. Everything else is implementation detail.

Practically:

You approve a worktree and an allowed action set before workers run.
After approval, the envelope does not expand. New folders, “just this one helper,” or silent scope creep are not part of the contract.
Workspace mutation stays in the approved worktree only. Callers cannot supply cwd; the server fixes it to that worktree.
Model talk stays on the host (Codex CLI / app-server path). Cue is not offline-only. Workspace actions run in AppContainer workers under the approved envelope.

Adjacent honesty from README Current limits: Cue does not remove Windows UAC/elevation friction, does not claim syscall-enforced network isolation for all paths (P3-16 is detect-and-stop, not syscall forcing), and does not support nested worker child processes in v0.1.

So “envelope” is not marketing fog. It is a freeze point you can review, then a hard refusal to grow after you click Approve.

What you see after — completed, blocked, human-required

A control loop without an honest ending is just a prettier YOLO.

Cue’s ledger surfaces provenance and outcome classes you can inspect:

Completed — The run finished inside the approved envelope with a recorded result.
Blocked — The system stopped work rather than quietly drifting. Blocked is a product signal, not a hidden failure to hide under a green check.
Human-required — The agent needs you again; the ledger says so instead of inventing progress.

That triad is how Cue answers “did it stay inside what I approved?” without asking you to scrub raw logs for every run.

Stop is part of the same contract. Hitting Stop terminates the active controller and workers — not a soft UI pause that leaves orphans chewing your worktree. If you care about mid-run kill-switches for coding agents, that is the behavior to verify against the README’s Stop evidence path, not a marketing slide.

A 34-second demo (and what it does not prove)

Watch the clip: cue-demo-en.mp4

It is a 34-second edited recording of a real small file-changing flow (checklist-style generation). You should see goal → envelope review → approve → ledger. That is the proof this post leans on: the control UX, not a wall of isolation tables.

What it does not prove:

Completion-time promises (edited length ≠ “your goal finishes in 34 seconds”).
Unlimited tooling or nested worker children.
That the UI language is English everywhere — the shipping UI is currently Korean; the demo is captioned/recorded for English viewers.

Good first tasks vs wrong-fit tasks (v0.1)

v0.1 is aimed at small, inspectable file-changing goals on Windows 11:

Create a focused file and open it.
Update a local page or checklist you can click through.
Make a change whose before/after you can hash and eyeball.

Wrong-fit (for now):

Goals that need nested worker subprocesses / child process trees inside a worker.
Research-only or summarize-only goals that change no files (goal verification is built around file-changing outcomes).
“Operate like a full unsupervised desktop developer” across the whole machine.

Those limits are intentional coherence, not temporary bashfulness. If your first experiment needs nested tooling or open-ended YOLO scope, Cue will feel frustrating — correctly. Start with a disposable worktree and a one-file goal.

Want the sandbox primitive story?

This article intentionally does not re-litigate OpenAI’s AppContainer rejection for Codex-shaped workloads. Cue’s isolation floor (capability-zero AppContainer workers, approved worktree, host vs worker split) is covered here:

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

For verification entry points without a Day2 evidence dump, see the README Verification section in the repo.

Try it / star if the loop is what you want

If your pain is “I want to approve before a coding agent runs — once, with a real envelope — then inspect what happened,” Cue is for that moment.

Star / clone: https://github.com/zenovis2-create/cue
Watch the demo: https://github.com/zenovis2-create/cue/blob/main/docs/assets/cue-demo-en.mp4
On Windows 11 with Codex CLI authenticated: npm install then npm start

Star if you want more envelope-first Windows agent work. Open an issue if an approved envelope was exceeded.

That feedback is more useful than applause. The product bet only holds if the freeze point stays frozen.

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

윤대한 — Thu, 10 Sep 2026 07:27:43 +0000

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:

Natural-language goals via Codex CLI
Only inside approved worktrees
Capability-zero AppContainer isolation
An execution envelope that does not expand after approval
Credentials not written into the UI or a ledger
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)

DEV Community: 윤대한

Describe Review Approve Inspect: A Coding Agent Loop Built for Control

The false choice — YOLO desktop vs approval fatigue

The four-step loop

What “execution envelope” means here

What you see after — completed, blocked, human-required

A 34-second demo (and what it does not prove)

Good first tasks vs wrong-fit tasks (v0.1)

Want the sandbox primitive story?

Try it / star if the loop is what you want

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

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

What Codex needed (and why AppContainer lost)

What Cue is optimizing for instead

AppContainer vs “sandbox theater”

UAC / elevated friction (honest)

How to read the Codex rejection next to Cue

What feedback actually helps

Links