grok-implementer: --permission-mode acceptEdits does not auto-approve write tool calls

[tobetchi]

Grok CLI 0.2.93 does not auto-approve write tool calls when --permission-mode acceptEdits is passed to grok --prompt-file. Write operations get canceled instead of being applied.

Falling back to --permission-mode auto resolves the issue — writes are approved automatically as expected.

Filed PR with this fix: #2

Note: since my Grok CLI was installed via Homebrew, the version may differ slightly from the official release channel — worth confirming whether this is version-specific behavior.

[abullaisi]

Reproduced independently on macOS, grok CLI 0.2.14, running the grok-implementer invocation exactly as pinned in the agent (--prompt-file … -m grok-4.5 --permission-mode acceptEdits --output-format plain --cwd …) on a fixture-repo task:

• exit code 0, grok's final message announced the implementation ("Implementing `--stats` with nearest-rank p95…")
• but git diff was empty — no edits ever landed, verification re-run failed on the untouched file

Re-running the identical spec with --permission-mode auto produced a correct 43-line diff that matched precomputed ground truth. So: confirmed silent no-op with acceptEdits headless, confirmed auto as the fix — supports #2 as-is.

(The exit-0 + confident-announcement + empty-diff shape is exactly the failure mode the agent's independent-re-verification rule catches. Nice design.)

[abullaisi]

Update: still reproduces on grok CLI 0.2.101 (stable) — roughly 87 releases after my 0.2.14 repro above. Headless --permission-mode acceptEdits remains a silent no-op (exit 0, plan announced, empty diff); --permission-mode auto still works. Persisting across the whole 0.2.x line suggests intended CLI semantics rather than a regression, which makes #2 the right fix for the pinned flags.

[nathanaelries]

Confirming this on a different platform and much newer CLI versions than the original report, with some extra diagnostic detail that may help pin it down.

Environment: Windows 11 Pro, grok CLI 0.2.106 (auto-updated itself to 0.2.111 mid-session, behavior unchanged), invoked headlessly by the grok-implementer agent (grok --prompt-file <spec> --permission-mode acceptEdits ...).

What we see, beyond the silent write no-ops described above:

1. Silent write no-op, confirmed. Exit code 0, no error on stdout/stderr, nothing lands on disk. Reproduced independently by two separate lane invocations, including a minimal "write hello.txt" test.
2. It is not limited to writes. When the model issues run_terminal_command, the entire turn is cancelled and all prior work in that call is discarded. --debug-file traces show "stopReason":"cancelled", "cancellationCategory":"PermissionCancelled".
3. Other modes are affected too. Reproduces under --permission-mode dontAsk, with and without --no-plan, and regardless of --cwd (a project dir with MCP servers vs. a clean scratch dir).
4. It looks like a race in the approval-resolution path, not a content-based denial. Across identical runs, sometimes 0 and sometimes 2 terminal calls pass (logged as an internal "policy" auto-allow) before the next call cancels the session. The allowed and cancelled calls were not meaningfully different.
5. Minimal repro: a 5-line prompt that only echoes text, no project context: same PermissionCancelled, 0/5 commands dispatched.
6. Resume trap: --resume of a session that stalled under acceptEdits stays broken even when resumed under --permission-mode auto; only a fresh invocation recovers.

We can confirm the workaround in the original report: --permission-mode auto writes reliably. The cost is blanket command approval, which the agent doc explicitly tries to avoid ("Never --always-approve"), so until the CLI fixes this upstream it may be worth landing PR #2 (or defaulting the lane to auto) and keeping the "verify the files actually landed" step mandatory, since acceptEdits failures are exit-0 silent.