"Accept edits" still prompts for file edits, and the prompt reads "The agent wants to run The agent is asking for permission?"

[pacifio]

Two bugs, same screen

Testing the permission modes end to end. Plan mode works correctly. Accept-edits does not, and the permission dialog it wrongly shows is also malformed.

0.3.3 @ 69c56bfd, Atlas Agent cersei, Claude Sonnet 4.6.

---

1. "Accept edits" prompts for a file edit

The mode describes itself as:

Accept edits — Auto-approve file edits; prompt for shell

Repro (reproduced twice, fresh thread each time):

1. Set mode to Accept edits — the composer pill confirms ● Accept edits.
2. Prompt: "Create a file called ACCEPTEDITS2.md containing the single word ok."
3. The agent calls apply_patch — a pure file edit, no shell.
4. A permission dialog appears anyway, for the edit:

{
  "paths": [ "C:\Users\…\sample-project\ACCEPTEDITS2.md" ],
  "patch": "ok\n"
}

Expected: auto-approved, no prompt. Shell commands should still prompt.

For contrast, Plan mode is correct: asked to create a file, the agent called no tools and nothing was written to disk.

2. The dialog title is two sentences glued together

The header renders as:

The agent wants to run The agent is asking for permission?

Both halves are identified:

src/features/chat/components/permission-modal.tsx:338

The agent wants to run <span …>{title}</span>?

src/features/chat/components/permission-modal.tsx:194

const title = current.toolCall.title ?? current.toolCall.kind ?? "Tool call";

crates/atlas-native-agent/src/engine/approvals.rs:129

let title = title
    .filter(|t| !t.trim().is_empty())
    .or_else(|| reason.clone().filter(|r| !r.trim().is_empty()))
    .unwrap_or_else(|| "The agent is asking for permission".to_string());

The Rust fallback is a sentence, written to guarantee the dialog is never empty — a good intention, and the comment above it says so. But the frontend already supplies the sentence frame and expects title to be a tool name. When apply_patch permission requests arrive with neither title nor reason, the fallback fires and the two sentences collide.

Suggested fix: make the fallback a noun phrase (e.g. the tool kind, or "a tool call"), so it reads "The agent wants to run a tool call?" — or have the approvals path pass the tool name through as the title, which would be strictly better since the user would see apply_patch.

Note — one thing I could not pin down

After clicking Allow, the turn showed "Editing files" and never completed; the file was never written. I saw this twice, but the first occurrence coincided with atlas_comms: could not reach the token endpoint warnings in the log, and on the retry I lost the thread selection before it resolved. Network was verified up afterwards (gateway reachable, TCP 443 open). Flagging it as unconfirmed rather than filing it — worth a look while fixing the above, since it would be on the same code path.

Environment

0.3.3 @ 69c56bfd, Windows 11, dev build, claude-sonnet-4-6, auth_mode=ApiKey.

[pacifio]

Half fixed in #295, half deliberately left — and I think the second half may not be a bug

Fixed: the malformed dialog title. The fallback in approvals.rs is now a noun phrase per tool kind — "a command", "a file edit", "a tool call" — so it composes with the sentence frame in permission-modal.tsx:338 instead of colliding with it. A test asserts the fallback never contains "The agent".

Not fixed: Accept-edits still prompting for a file edit. I went to fix this and stopped, because the obvious change would be wrong:

crates/atlas-native-agent/src/engine/modes.rs:105

"acceptEdits" => (AskForApproval::OnRequest, workspace_write()),

AskForApproval is a global policy, not per-tool. Setting it to Never to auto-approve edits would also silence shell approvals — the exact opposite of what the mode promises ("Auto-approve file edits; prompt for shell").

There is also a platform dimension. prepare_apply_patch routes through assess_patch_safety(..., turn_context.windows_sandbox_level) (vendor/codex/core/src/apply_patch.rs:22), and Atlas never sets windows_sandbox_level — it is derived inside the engine. On Windows without an enforceable sandbox, asking before a write is plausibly the correct fail-safe, in which case the bug is the mode's description promising something the platform cannot deliver, not the mapping.

So this needs a decision rather than a patch:

1. per-tool approval (edits auto, shell prompts) — needs engine support, since one policy currently covers both; or
2. keep the behaviour and change the mode's description on platforms without a sandbox, so it stops promising auto-approval it will not give.

Worth confirming on macOS/Linux first: if Accept-edits auto-approves there and only Windows prompts, that settles it as the sandbox path rather than the mapping. I only tested Windows.

One more thing, still unconfirmed

After clicking Allow, the turn showed "Editing files" and never completed; the file was never written. Seen twice. The first occurrence coincided with atlas_comms: could not reach the token endpoint warnings, and network was verified up afterwards. I could not reproduce it cleanly, so I am not filing it — but it is on this code path and worth watching for while changing the above.

[pacifio]

Root cause found — it is one config default, not a mapping bug

I traced this properly. Accept-edits prompting on Windows is the engine deliberately refusing to auto-approve a write it cannot sandbox, and the reason it cannot is a default Atlas never overrides.

vendor/codex/core/src/safety.rs:71

// Only auto-approve when we can actually enforce a sandbox. Otherwise
// fall back to asking the user because the patch may touch arbitrary
// paths outside the project.
match get_platform_sandbox(windows_sandbox_level != WindowsSandboxLevel::Disabled) {
    Some(_) => SafetyCheck::AutoApprove,
    None    => SafetyCheck::AskUser,
}

vendor/codex/sandboxing/src/manager.rs:62

if cfg!(target_os = "macos")   { Some(SandboxType::MacosSeatbelt) }
else if cfg!(target_os = "linux") { Some(SandboxType::LinuxSeccomp) }
else if cfg!(target_os = "windows") {
    if windows_sandbox_enabled { Some(SandboxType::WindowsRestrictedToken) } else { None }
}

vendor/codex/protocol/src/config_types.rs:279

pub enum WindowsSandboxLevel {
    #[default]
    Disabled,
    RestrictedToken,
    Elevated,
}

So: macOS and Linux always have a sandbox, so Accept-edits auto-approves there and the mode behaves as written. Windows has one — WindowsRestrictedToken — but it is opt-in, the default is Disabled, and Atlas never sets it. No sandbox means no auto-approve, so every edit prompts.

This also means Windows agent execution is currently unsandboxed entirely, which is the larger finding. The prompt is the symptom; the missing sandbox is the thing.

Two ways to close it

1. Enable the Windows sandbox (windows_sandbox_level = RestrictedToken in the engine config Atlas writes). Fixes the mode, and gives Windows the containment macOS and Linux already have.

The caveat is real: this would sandbox all agent execution on Windows for the first time. A restricted token can break commands that currently work, and nothing in this app has ever exercised that path. It wants a deliberate test pass — I have the harness set up and can run it if wanted, but it should not be flipped blind.

2. Make the description honest. Leave the behaviour and stop promising auto-approval the platform cannot deliver, e.g. platform-aware copy in modes.rs. Cheap and safe, but leaves Windows unsandboxed.

My recommendation is (1), tested, with (2) as the fallback if the sandbox turns out to break real workflows.

What was fixed

The dialog-title half is done and merged in #295 — the fallback is now a noun phrase per tool kind, so it no longer renders "The agent wants to run The agent is asking for permission?".

Correcting myself

My earlier comment said this "may be correct fail-safe behaviour" and left it there. That was half right — it is fail-safe — but I stopped before finding that the safety check is gated on a setting Atlas controls. It is not a platform limitation; it is a default.