web_issue trigger omits request context — agent cannot learn the ask (least-privilege token has no issues:read)

Open
#23 3 comments 0 reactions 0 assignees View on GitHub

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
Domain
api, backend

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

bug

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, no issues:read, even though the App installation itself has issues: write).
  • Facility platform API via $FACILITY_PLATFORM_KEY403 forbidden (key lacks issues: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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from theam/facility

All issues in theam/facility

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.