agent-sdk-driver never grants Read/Bash tool access, unlike the CLI driver's #6840 fix it claims to mirror

[JSONbored]

Context

packages/loopover-engine/src/miner/agent-sdk-driver.ts is the Agent-SDK implementation of the CodingAgentDriver seam, the in-process sibling of cli-subprocess-driver.ts. Its run() method (line 152-168) builds the SDK session with only:

const stream = query({
  prompt: task.instructions,
  options: {
    cwd: task.workingDirectory,
    maxTurns: task.maxTurns,
    // Same edit-permission scope as the CLI-subprocess driver (#4266): `--permission-mode acceptEdits`
    // there, `acceptEdits` here — file edits run unattended inside the scoped worktree, nothing broader.
    permissionMode: "acceptEdits",
    hooks: options.hooks,
  },
});

AgentSdkQueryOptions (line 29-34) structurally declares only cwd, maxTurns, permissionMode: "acceptEdits", and hooks — there is no allowedTools field at all, so nothing in this driver can ever pass one.

Its CLI-subprocess sibling had exactly this same gap and was fixed as #6840, whose fix is documented in detail at cli-subprocess-driver.ts:87-104:

--permission-mode acceptEdits alone (the CLI's own edit-permission scope, matching the label the Agent-SDK driver's permissionMode also uses, #4267) only auto-approves file EDIT tool calls -- it does NOT grant Read or Bash, so a real task (which needs both to explore the repo and run tests) got every one of those calls denied in a headless --print invocation with no TTY to resolve an interactive prompt, silently producing zero real work every time (#6840). --allowedTools Read Bash grants exactly the two additional tool classes the task actually needs...

The CLI driver's fix (defaultClaudeCliArgs, line 109) now passes --allowedTools Read Bash alongside --permission-mode acceptEdits. The Agent-SDK driver's own comment (agent-sdk-driver.ts:162-164) explicitly claims parity — "Same edit-permission scope as the CLI-subprocess driver" — but the actual Read/Bash allowlist half of that fix was never ported to this driver. The @anthropic-ai/claude-agent-sdk's permission-evaluation model does not implicitly grant Read/Bash from acceptEdits mode alone (this is the exact class of gap #6840 fixed for the CLI side); this package's own chat-grounding.ts (same miner/ directory) independently proves the SDK's real query() accepts an allowedTools option — it sets one (allowedTools: CHAT_GROUNDING_TOOL_NAMES) for its own, unrelated session.

If the SDK's acceptEdits mode has the same Read/Bash gap the CLI mode had, every live coding-agent attempt routed through createAgentSdkCodingAgentDriver silently produces zero real work (every Read/Bash tool call denied) while still returning a structured result message that looks like a completed, successful iteration — a wrong-but-plausible "success" with an empty diff, exactly #6840's failure mode, just on the sibling driver.

Requirements

• Add an allowedTools field to AgentSdkQueryOptions (and to CreateAgentSdkDriverOptions if it needs to be caller-configurable, matching how hooks is already threaded through) so the SDK session can be given an explicit tool allowlist.
• run() must pass allowedTools: ["Read", "Bash"] (or the SDK's equivalent tool-name spelling — verify against how chat-grounding.ts names its own CHAT_GROUNDING_TOOL_NAMES entries) alongside permissionMode: "acceptEdits", mirroring the CLI driver's --allowedTools Read Bash fix for claude-cli driver's --permission-mode acceptEdits denies every Read/Bash call, silently blocking all real work #6840.
• Update the stale "Same edit-permission scope as the CLI-subprocess driver" comment at agent-sdk-driver.ts:162-164 to accurately describe both the acceptEdits mode AND the allowedTools grant, matching the level of detail in the CLI driver's own comment.
• Do not use a broader permission mode (e.g. bypassPermissions) to work around this — the CLI driver's own comment explicitly rejects that as "disabl[ing] edit-scope confirmation and any other safety rail the CLI has, not just the Read/Bash gap this task actually hits." Grant exactly Read/Bash, nothing broader.

Deliverables

• allowedTools: ["Read", "Bash"] passed on the SDK session options in createAgentSdkCodingAgentDriver's run()
• AgentSdkQueryOptions type updated to include the new field
• Doc comment at the permissionMode/session-options call site corrected to describe the actual grant (mode + allowlist), not just the mode
• Regression test using the existing injected-AgentSdkQueryFn test harness asserting the session options passed to query() include allowedTools containing Read and Bash

Test Coverage Requirements

This repo's Codecov patch gate is 99%+ hard (branch-counted) on every changed line/branch in src/**/packages/**. The regression test must assert the exact allowedTools value reaching query()'s options, not just that the driver "works" — this is a config-shape bug, so the test must inspect the constructed options object directly (same style as the existing driver-construction tests in test/unit/agent-sdk-driver.test.ts).

Expected Outcome

The Agent-SDK driver grants the coding agent Read and Bash tool access the same way the CLI-subprocess driver does post-#6840 — no more silent zero-work "successful" iterations from this driver caused by every exploration/test-running tool call being denied.

Links & Resources

packages/loopover-engine/src/miner/agent-sdk-driver.ts:29-34 (the options type missing the field), :152-168 (run(), the session construction), :162-164 (the stale parity comment). packages/loopover-engine/src/miner/cli-subprocess-driver.ts:87-109 (defaultClaudeCliArgs, the sibling's #6840 fix and its detailed doc comment). packages/loopover-engine/src/miner/chat-grounding.ts:265 (proof the SDK's query() accepts allowedTools).

[linear-code]

JSO-5018