Summary
Computer can comment on issues and pull requests and can open draft pull requests, but it cannot create an issue. Today a proposal that Computer drafts has to be pasted into the GitHub UI by a person. This proposes a scoped write path so Computer can file issues directly, with the same human gates the rest of the factory uses.
This came up concretely: Computer drafted a proposal for a factory activity view and could not file it. The asymmetry is odd, since opening a draft PR is a larger write than opening an issue.
Problem
The GitHub channel is deliberately narrow: comments on the working thread, and draft PRs after a review passes. Issue creation is outside it.
Drafting an issue and handing it over loses structure. Copy-pasting through a browser strips the connection between the drafting conversation and the filed item.
A maintainer must be present to file anything, which blocks unattended runs from proposing follow-up work they discover mid-run.
Proposed behavior
A dedicated tool, create_issue, scoped to the verified repository only. Not a general write path.
Authorization follows the existing model: an active member of the configured approver team, or a recognized unattended factory run.
Approval gate before the call executes. Opening an issue is externally visible, so it should sit behind the same human-in-the-loop confirmation that other external actions use.
Every created issue carries a marker identifying it as agent-filed, plus the originating run ID, so the path is auditable.
Idempotency keyed on (run ID, work item) so a retry or a replayed webhook does not open a duplicate.
Labels are restricted to the repository's existing vocabulary. The tool does not create labels.
Creation is capped per run, with the cap configurable.
Safety and scope
Repository access stays limited to the verified GitHub context. No arbitrary owner or repo.
Issue bodies are untrusted content. A body Computer files must not be able to alter Computer's own instructions or widen its scope on later reads, since filed text becomes input on the next pass. This boundary must be solved and tested before this capability ships.
No label creation, no assignee changes, no closing of issues through this path.
No secrets, credentials, or raw run content in a filed body.
Denial and rate limits logged to the redacted run history.
Acceptance criteria
- Computer can create an issue in the verified repository through the dedicated tool only.
- The call requires approval before it executes.
- Created issues carry an agent-filed marker and their run ID.
- A retried or replayed call does not create a duplicate issue.
- The tool cannot target a repository outside the verified context.
- The tool cannot create labels or make changes beyond the issue body, title, and existing labels.
- Per-run creation is capped.
- A filed body is treated as untrusted input on subsequent reads, and tests cover a hostile body.
- Authorization failures are denied by default and logged.
Open questions
Should the approval gate be per issue, or one approval covering a batch filed in a single run?
Does this belong in the GitHub channel, or as a station output that a person promotes? The second keeps the human boundary intact but adds a queue.
Should agent-filed issues enter the standard intake labels automatically, or land unlabeled for a maintainer to classify?
Relationship to existing work
Related to #12 (deliberate intake and promotion boundary) but on the outbound side: #12 governs what enters the pipeline, this governs what Computer may file. Distinct from #47, which is about review comments on existing pull requests.
This capability should not ship until its untrusted-input boundary is implemented and reviewed.
Summary
Computer can comment on issues and pull requests and can open draft pull requests, but it cannot create an issue. Today a proposal that Computer drafts has to be pasted into the GitHub UI by a person. This proposes a scoped write path so Computer can file issues directly, with the same human gates the rest of the factory uses.
This came up concretely: Computer drafted a proposal for a factory activity view and could not file it. The asymmetry is odd, since opening a draft PR is a larger write than opening an issue.
Problem
The GitHub channel is deliberately narrow: comments on the working thread, and draft PRs after a review passes. Issue creation is outside it.
Drafting an issue and handing it over loses structure. Copy-pasting through a browser strips the connection between the drafting conversation and the filed item.
A maintainer must be present to file anything, which blocks unattended runs from proposing follow-up work they discover mid-run.
Proposed behavior
A dedicated tool,
create_issue, scoped to the verified repository only. Not a general write path.Authorization follows the existing model: an active member of the configured approver team, or a recognized unattended factory run.
Approval gate before the call executes. Opening an issue is externally visible, so it should sit behind the same human-in-the-loop confirmation that other external actions use.
Every created issue carries a marker identifying it as agent-filed, plus the originating run ID, so the path is auditable.
Idempotency keyed on
(run ID, work item)so a retry or a replayed webhook does not open a duplicate.Labels are restricted to the repository's existing vocabulary. The tool does not create labels.
Creation is capped per run, with the cap configurable.
Safety and scope
Repository access stays limited to the verified GitHub context. No arbitrary owner or repo.
Issue bodies are untrusted content. A body Computer files must not be able to alter Computer's own instructions or widen its scope on later reads, since filed text becomes input on the next pass. This boundary must be solved and tested before this capability ships.
No label creation, no assignee changes, no closing of issues through this path.
No secrets, credentials, or raw run content in a filed body.
Denial and rate limits logged to the redacted run history.
Acceptance criteria
Open questions
Should the approval gate be per issue, or one approval covering a batch filed in a single run?
Does this belong in the GitHub channel, or as a station output that a person promotes? The second keeps the human boundary intact but adds a queue.
Should agent-filed issues enter the standard intake labels automatically, or land unlabeled for a maintainer to classify?
Relationship to existing work
Related to #12 (deliberate intake and promotion boundary) but on the outbound side: #12 governs what enters the pipeline, this governs what Computer may file. Distinct from #47, which is about review comments on existing pull requests.
This capability should not ship until its untrusted-input boundary is implemented and reviewed.