assign_copilot_to_issue_with_intent assigns Copilot but the agent session never starts

[A-Georgiou]

Summary

assign_copilot_to_issue_with_intent reports success and Copilot is genuinely assigned to the issue, but no coding agent session is ever created. The user sees:

The agent encountered an error and was unable to start working on this issue: This may be caused by a repository ruleset violation. See granting bypass permissions for the agent, or please contact support if the issue persists.

Assigning Copilot manually to the same repository, moments later, works end to end.

That error text is misleading: I checked, and no ruleset denial occurred (details below). Granting bypass permissions will not help, so it is worth correcting expectations for anyone who hits this.

Reproduction

Observed on github/padawan-testing-staging-jedi-knight (repo id 1042304088), issue #1065, 2026-09-15 14:00 UTC.

Tool call, from the calling agent's log:

{"owner":"github","repo":"padawan-testing-staging-jedi-knight","issue_number":1065,
 "is_suggestion":false,"confidence":"HIGH",
 "rationale":"Issue requests repository research and a report, ...",
 "custom_instructions":"Continue the repository research requested in the issue ..."}

Result (success=true):

{"is_suggestion":false,"issue_number":1065,"message":"successfully assigned copilot to issue - pull request pending", ...}

Evidence

Comparing the failing tool-driven assignment (#1065) against a manual assignment on the same repo two minutes later (#1066), from request logs:

Step	#1065 (tool)	#1066 (manual)
GraphQL updateIssue	200	200
UpdateIssueOrchestration	completed 14:00:11.679	completed
GET /repos/.../rules/branches/copilot/task-...	never called	200 at 14:01:27.9
GET /repos/.../agents/secrets and /agents/variables	never called	200 at 14:01:30
"Copilot SWE agent job secret mint result"	absent	3x at 14:02:38-42

So the assignment mutation succeeds and the orchestration completes, but nothing downstream ever runs.

On the ruleset claim: every Repositories::RuleSuite evaluation for this repo in the window was on refs/heads/main for the other PR's merge check (license compliance + required workflows). Nothing evaluated a copilot/* branch for #1065.

Where the two paths diverge

The intent tool uses the object form, whereas the legacy tool and the UI use assignee IDs:

• AssignCopilotToIssue (pkg/github/copilot.go): UpdateIssueInput{ AssigneeIDs: actorIDs, AgentAssignment: ... }
• AssignCopilotToIssueWithIntent: UpdateIssueInput{ Assignees: assignees }, with AgentAssignment set only when !IsSuggestion

github/github declares these mutually exclusive and handles them on separate branches in app/platform/mutations/update_issue.rb. The object form routes through process_intents_via_processor, sets agent_bots_prevalidated = true, and takes a different validation branch (validate_agent_assignment_authorization! rather than validate_agent_bot_assignments!).

Candidate mechanisms

I could not discriminate between these without stepping through the intent processor at runtime, so I am listing them rather than asserting one.

1. The writable_by? strip. update_issue.rb:384-390 adds a Forbidden execution error and then removes the new agent bots from attributes.assignees while continuing with the rest of the update. copilot_context stays nil, so no token is minted and no session starts. Because the intent processor persists the assignment atomically via trigger_assigned_event (see the comment at :255), the issue can still show Copilot assigned. This matches the symptom most closely.
2. The copilot_context gate. update_issue.rb:374-382 only builds copilot_context when inputs.key?(:assignees) && present? and a new agentic bot id is found. inputs[:assignees] is left unset when applied_actors is empty (:268-270).
3. Empty-string customAgent. Both assign tools send CustomAgent: &emptyString; omitempty on *githubv4.String only drops a nil pointer, so "customAgent": "" goes on the wire where the UI omits it. This is common to both tools, so it does not by itself explain why only the intent tool fails, but it is worth tightening regardless.

Suggested next step

The cheapest discriminator is a direct GraphQL call: updateIssue with object-form assignees plus agentAssignment, against a repo where the caller is known to be writable, then check whether a job secret mint follows. If mechanism 1 is correct, the response will carry a Forbidden execution error alongside a successful-looking payload.

Independently of the root cause, two small hardening changes look worthwhile in this repo:

• Only populate CustomAgent / CustomInstructions when non-empty, rather than pointing at "".
• Surface GraphQL execution errors from the assignment mutation in the tool result, so the tool does not report success when the agent assignment half of the mutation was rejected.

Filed from an investigation into why automations that select this tool never produce a session. Happy to provide the full request-log trace.

[A-Georgiou]

Additional code-reading evidence for mechanism 1, found after filing.

The two assignment paths do not just diverge in which validator they call, they diverge in how much is validated before the agent-assignment step. update_issue.rb:283-291:

if agent_bots_prevalidated
  # Object form: enablement already filtered; only the token/authorization gate remains.
  validate_agent_assignment_authorization!(repository, actor: context[:viewer])
else
  validate_agent_bot_assignments!(bots, repository, actor: context[:viewer])
end

agent_bots_prevalidated is set to true only on the object-form branch, so the intent tool takes the first path.

That first validator (app/platform/helpers/agentic.rb:47-58) checks exactly one thing, and its comment is the interesting part:

# Agent assignment is not supported via GitHub App installation tokens
# (server-to-server). Only user tokens (personal access tokens and OAuth
# tokens) are permitted. Without this check, the mutation would later
# fail with the misleading "target repository is not writable" error
# because installation tokens cannot be checked with `writable_by?`.
if @context[:permission]&.integration_bot_request?

So there is a known, documented failure mode in which a token that cannot be evaluated by writable_by? falls through to precisely the "target repository is not writable" branch at update_issue.rb:384, which strips the agent bot from attributes.assignees and continues. That is mechanism 1, and this comment says the outcome is expected to be a misleading error rather than a clear one, which fits the unhelpful user-facing message.

Worth checking whether the guard's integration_bot_request? condition actually covers the token type used here. In the failing request the GraphQL logs show gh.graphql.integration_id set with a viewer_login of a real user, so it was not rejected by the guard, yet the downstream writable_by? branch is still reachable. If the guard's condition is narrower than the set of tokens writable_by? cannot evaluate, the gap between the two is where this lands.

If that is confirmed, the fix is likely on the github/github side rather than in this repo, but the two hardening items in the original description still apply here: do not send customAgent: "", and surface GraphQL execution errors so the tool stops reporting success when the agent-assignment half of the mutation was rejected. The second one matters independently, because today the tool tells the caller the assignment succeeded and a pull request is pending when no session was ever created.