Repository navigation
H4b: "trust this issue" action and a runner guard for untrusted issues #108
Description
Who this is for: whoever builds lane H's last step (H4b), and reviewers of lanes F and G.
What it covers: the "trust this issue" action, and the runner guard that makes trust matter.
Summary
- Today, an issue whose author is not a repository collaborator shows "! Needs trust" on the Issues screen, but nothing records a trust decision and nothing enforces one.
POST /api/runnerstartandresume(F: wire the runner and startup recovery into the server #91, PRs F: wire the runner and startup recovery into the server (#91, part 1) #102 and F: start and resume a task's plan through /api/runner (#91, part 2) #105) run a task's plan without checking who wrote its issue. So an issue from anyone can reach an execute agent.- H4b adds a recorded trust decision, a guard on the runner, and the action on the Issues screen.
Why
The design ("Keeping unattended runs safe", "Which issues can be queued" and "Which comments reach the agent"):
- By default, only issues written by repository collaborators can be queued.
- Other issues need you to click "trust this issue". codeboost records that choice.
- By default, only collaborators' comments reach the agent. After "trust this issue", other people's comments are included too, inside the same data block.
- Every invocation records which comments it was given.
docs/implementation/issue-prioritization.md (H4b) says the trust record goes through the Store owner (lane F) after F1's Store changes. Those have landed (F1a, #53, and later migrations up to schema v9), so H4b is unblocked.
What exists
| Piece | Where | State |
|---|---|---|
| Trust classification | github/issues.ts: trust: 'trusted' | 'requires-approval', from the repository's current collaborator list (not author_association; see #41, #42) |
Done |
| Trust mark on the Issues screen | web/public/app.js: "✓ Collaborator" or "! Needs trust" |
Done |
| Collaborator-only comments in execute prompts | GhIssueGateway.issueText |
Done |
| Recorded trust decision | — | Missing |
| Runner guard | start, resume in web/server.ts (runChoice), ItemExecutor.begin |
Missing |
| Record of comments given to each invocation | — | Missing |
Needed
- Store. A trust record keyed by repository identity and issue number. It holds who decided, when, and the issue author login at that time. Use an append-only record or one row per issue with a revoke. A schema version bump with a migration test.
- Trust is scoped to one repository. An issue number alone never matches (AGENTS.md: preserve repository identity).
- If the issue's author changes (for example, the account is deleted and becomes
ghost), the earlier decision no longer applies.
- Runner guard.
startandresumerefuse a task whose issue is neither written by a current collaborator nor trusted. The check reads the author and collaborator list from GitHub at admission (bounded, fail closed: a read that fails or is incomplete refuses). It uses the same rules asGhIssueGateway. A refusal is a recorded, definite outcome like the other/api/runnerrefusals. - Comments after trust. For a trusted issue,
issueTextincludes every comment, still as untrusted data in the same block. For an untrusted collaborator-written issue, behaviour does not change. - Comment record. Each execute attempt records which comments its prompt carried (comment IDs or a digest plus count), so a person can see what the agent was given.
- API and screen.
POST /api/issueswith{"action":"trust", ...}and{"action":"untrust", ...}, with an idempotency key and the issue's current author as a precondition. The Issues screen gets the button and shows "✓ Trusted by you on ". FollowDESIGN.md. Keep focus on the control while the request runs (AGENTS.md, "Async review UI"). Remove the note that says trusting is not available. - Demo mode. The action works against fixture issues and never contacts GitHub.
Questions to decide before coding
- Does trust also let a planning invocation include non-collaborator comments, or only execute? (Planning is not yet live; lane G.)
- Is revoking trust allowed while a task for that issue is running? Suggested: allowed, but it applies only at the next admission. A running attempt is not stopped.
- Should the guard also run before publishing a PR (F: publish a finished task's pull request in production #103), in case trust was revoked after the run?
Done when
- Tests show
startandresumerefuse an untrusted issue, and run it after trust is recorded. - Tests show a failed or incomplete collaborator read refuses.
- Tests show trust for
owner/a#5does not apply toowner/b#5. - Tests show a trusted issue's prompt includes non-collaborator comments, and an untrusted one does not.
- The attempt record lists the comments supplied.
- Browser tests cover the button, focus, stale responses and demo mode.
docs/implementation/issue-prioritization.mdgets an H4b section.
Related: #41, #42, #55 (H4a), #91, #103, #107.
🤖 Generated with Claude Code
Activity
Bring the architecture doc up to date with main (#131)