claude-cli driver's --permission-mode acceptEdits denies every Read/Bash call, silently blocking all real work

[JSONbored]

Problem

@loopover/miner's claude-cli coding-agent driver invokes Claude Code with --permission-mode acceptEdits (defaultClaudeCliArgs, packages/loopover-engine/src/miner/cli-subprocess-driver.ts:102-104). In practice, acceptEdits only auto-approves file edit tool calls — it does not grant Read or Bash access. Every real coding task needs to read the target file(s) and (per the acceptance-criteria contract itself) run the repo's test suite before finishing, so every Read/Bash call gets silently denied in a headless --print invocation with no TTY to resolve an interactive permission prompt.

Reproduction

Found while running AMS's full discover -> plan -> code -> PR loop end-to-end against a real repo (part of the AMS standalone-usage verification work, #6205). Two separate real loopover-miner attempt <owner/repo> <issue#> --live runs against the same real, small, well-scoped issue both aborted in under 1.5 seconds with zero driver turns:

attempt_log_events: "Self-review could not conclusively determine pass/fail: driver run did not
  complete successfully: claude_code_error_success Downgrading to abandon rather than optimistically
  handing off." (repeated identically on a second, independent retry)

claude_code_error_success comes from claudeErrorStatus (cli-subprocess-driver.ts:213-218) reading a self-contradictory is_error: true + subtype: "success" envelope back from the claude CLI subprocess -- itself a symptom of the underlying permission wall, not a separate bug in the error-parsing code.

To isolate the cause, I ran the same real issue's instructions directly against claude --print --output-format json (bypassing AMS entirely), from the exact worktree AMS had prepared:

• --permission-mode acceptEdits (AMS's actual current flag): completed after 31 turns / $0.59, but 19 of 19 tool calls (Read on the acceptance-criteria file, Bash for npm test/npm run lint, tried repeatedly with several different invocation shapes) were denied. Zero real work done -- no file was ever read, no fix was ever made, no test was ever run. is_error happened to read false in this particular run (unlike the two real AMS attempts, which hit is_error: true), but the outcome is identical either way: nothing gets accomplished.
• --permission-mode bypassPermissions: 0 denials, 47 turns, real work completed -- the agent read the real source, made the correct one-line interpolation fix, added a regression test, and verified it against the acceptance-criteria document.

Root cause

acceptEdits is not sufficient scope for AMS's actual task shape (explore the repo -> read acceptance criteria -> edit -> run tests -> verify). The flag comment (cli-subprocess-driver.ts:95-96) says this was deliberately chosen to match "the same edit-permission scope the Agent-SDK driver already uses (#4267)" -- worth double-checking whether the Agent-SDK driver (agent-sdk-driver.ts) actually grants broader tool access through a different mechanism (a permission callback, rather than the CLI's built-in --permission-mode) that the claude-cli subprocess driver never picked up an equivalent for.

There is currently no env var or CLI flag anywhere in @loopover/miner to override this -- buildArgs is only overridable programmatically (CliSubprocessDriverOptions.buildArgs), with no wiring from attempt-cli.js/coding-agent-construction.js to change it without a source patch.

Impact

This affects every live attempt run through the claude-cli provider today -- as currently configured, it cannot complete a real coding task end-to-end; it either denies its way to a no-op "success" or (as seen in both real attempts here) errors out near-instantly. This is very likely why #6205's live end-to-end verification could not produce a real completed PR through this driver.

Suggested scope for a fix (not investigated further here -- this issue is the bug report, not the fix)

• Change defaultClaudeCliArgs's permission mode to something that actually grants Read/Bash access for a scoped, single-attempt worktree. bypassPermissions is confirmed to work, but it's a strictly broader grant than the task needs (it also bypasses whatever safety rails a narrower permission set would keep) -- worth a deliberate decision on exactly what to grant (e.g. Claude Code's tool-specific allow-list flags, if any exist for non-interactive Read/Bash scoped to the working directory) rather than reflexively using the broadest option.
• Add a regression test asserting the claude-cli driver's real argv grants at least Read + Bash in addition to edits (the existing tests, per the file's own header comment, appear to be argv-shape assertions rather than live-CLI-behavior assertions -- this exact gap slipped past them).

Note: this blocked completing part of a verification pass

This bug is why the live-attempt portion of AMS's standalone-usage verification (#6205) could not produce a real, completed PR against a test issue -- both live attempts aborted before any real driver work happened, for the reason documented above.

[linear-code]

JSO-4723