fix(miner): grant Read/Bash in the agent-sdk driver's tool allowlist (#7245)

[xfodev]

Summary

agent-sdk-driver.ts's run() built its Agent-SDK session with permissionMode: "acceptEdits" but no tool
allowlist (AgentSdkQueryOptions had no allowedTools field at all). As documented for its CLI-subprocess
sibling's identical gap (fixed in #6840), acceptEdits only auto-approves file edit tool calls — it does
NOT grant Read or Bash. So a real headless task, which needs both to explore the repo and run tests, had
every one of those calls denied and the driver silently produced zero work.

This adds allowedTools: ["Read", "Bash"] to the session (matching the CLI driver's --allowedTools Read Bash),
adds the field to AgentSdkQueryOptions, and updates the stale "same edit-permission scope" comment to describe
both the acceptEdits mode and the Read/Bash grant. Per the CLI driver's own reasoning, this deliberately
does NOT widen to bypassPermissions, which would drop every other safety rail rather than closing just the
Read/Bash gap the task hits.

Closes #7245

Scope

• Conventional Commit title; focused (one module + its test); no site//CNAME/lovable; no new dependency.
• Linked a currently open issue (Closes #7245).

Validation

• git diff --check
• npm run typecheck (root — clean)
• npm run test:coverage — 100% of the changed lines covered. The driver's option-mapping test now asserts
  options.allowedTools === ["Read", "Bash"] alongside the existing permissionMode/hooks assertions; all
  existing agent-sdk-driver tests pass unchanged.
• npm run build:miner (engine builds clean).

If any required check was skipped, explain why:

• Change confined to packages/loopover-engine/src/miner/** (one module + one test); CI runs the full suite incl. driver-parity.

Safety

• No secrets, wallets, hotkeys, coldkeys, PATs, trust scores, or private data exposed.
• Public GitHub text stays sanitized and low-noise.
• No auth/CORS/session/API/OpenAPI/MCP surface change. The permission scope is NARROWED-to-explicit, not widened: exactly Read + Bash are allowed, bypassPermissions is explicitly avoided, edits stay acceptEdits-scoped inside the worktree.
• No UI change — no UI Evidence needed.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.81%. Comparing base (e66f869) to head (55a2296).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7276   +/-   ##
=======================================
  Coverage   93.81%   93.81%           
=======================================
  Files         704      704           
  Lines       69460    69460           
  Branches    18899    18899           
=======================================
  Hits        65164    65164           
  Misses       3302     3302           
  Partials      994      994           

Flag	Coverage Δ
shard-1	43.60% <ø> (ø)
shard-2	37.33% <ø> (+0.10%)	⬆️
shard-3	33.18% <ø> (+0.08%)	⬆️
shard-4	33.74% <ø> (-0.59%)	⬇️
shard-5	32.89% <ø> (+0.70%)	⬆️
shard-6	45.48% <ø> (-0.30%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ages/loopover-engine/src/miner/agent-sdk-driver.ts	100.00% <ø> (ø)

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-19 12:10:28 UTC}

2 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This adds `allowedTools: ["Read", "Bash"]` to the agent-sdk driver's session options, mirroring the CLI-subprocess driver's `--allowedTools Read Bash` fix from #6840, closing a real gap where `acceptEdits` alone only auto-approves file edits and silently denies Read/Bash tool calls needed for a headless task to explore the repo and run tests. The change is minimal and correctly scoped (not widened to `bypassPermissions`), the type is updated, and the test asserts the new field is passed through verbatim to the captured query options. Diff is small, well-targeted, and closes a linked issue (#7245) with a matching test.

Nits — 2 non-blocking

• nit: `allowedTools` is typed as `readonly string[]` on `AgentSdkQueryOptions` (agent-sdk-driver.ts:33) rather than a literal tuple type like `readonly ["Read", "Bash"]` or a union of tool names, so a typo like `allowedTools: ["Read", "Baash"]` would typecheck silently — consider a stricter type if the SDK exports one.
• Consider whether other tools (e.g. Grep/Glob) are also silently denied under acceptEdits and would hit the same failure mode in a future task — worth a follow-up issue rather than blocking this narrow fix.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#7245
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 27 registered-repo PR(s), 16 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	xfodev; Gittensor profile; 27 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff adds allowedTools to AgentSdkQueryOptions, passes allowedTools: ["Read", "Bash"] alongside permissionMode: "acceptEdits" in run(), corrects the stale parity comment, and adds a regression test asserting the exact allowedTools array reaches the query() options — matching all stated requirements without widening to bypassPermissions.

Review context

• Author: xfodev
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: JavaScript, TypeScript
• Official Gittensor activity: 27 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.