web_issue trigger omits request context — agent cannot learn the ask (least-privilege token has no issues:read)
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- github, typescript
Research direction
Start at POST /v1/projects/:projectId/issues/:number/trigger and trace the web_issue path, then compare it with routeTrigger and githubRequestContext. Check how synced ghIssues data enters the trigger and use run_019f8177e2b671a2a3052fe29bef8a2d as evidence. Done means a web_issue run can access the triggering issue title and body without requiring additional issue-read permissions.
Written by the indexing model from the issue text.
Description
Found while dogfooding the platform lane on a live deployment.
What happened
Triggering an agent from the control plane (POST /v1/projects/:projectId/issues/:number/trigger, trigger type web_issue) creates a run whose trigger payload carries only the issue number — unlike the GitHub-comment path, where routeTrigger embeds request: githubRequestContext(payload) precisely because "without this context an agent only received numeric GitHub IDs and could not know what work the user requested".
The architect then tried every channel to learn the ask and hit walls by design:
- GitHub REST via the run's installation token →
403 Resource not accessible by integration(run-scoped token is minted least-privilege, noissues:read, even though the App installation itself hasissues: write). - Facility platform API via
$FACILITY_PLATFORM_KEY→403 forbidden(key lacksissues:read/projects:read/tasks:read).
The agent (correctly) refused to fabricate a plan and stopped at Human Gate 1 asking for the issue text. Evidence: run run_019f8177e2b671a2a3052fe29bef8a2d, the run’s progress comment.
Expected
A web_issue-triggered run should be self-sufficient: embed the synced issue title/body from ghIssues into the trigger (the platform already has it — the issue is synced), mirroring githubRequestContext. Alternatively (or additionally), scope the run's platform key to read its own triggering issue.
Why it matters
The web trigger is the UI's primary affordance; today it produces a run that cannot know what was asked, which reads as a broken product experience unless the user happens to know the comment path works differently.
- Dominant language
- TypeScript
- Stars
- 71
- Forks
- 64
- Avg merge
- 15h 38m
- Merged PRs (30d)
- 66
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from theam/facility
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Similar issues
-
clawsweeper:fix-shape-clear clawsweeper:queueable-fix clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster no-stale P3
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 76/100
-
code-quality refactoring
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
github/gh-aw-firewall#8816 ·
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
vercel/react-tweet#225 ·