Spike 2952: Copilot CLI attach-to-issue UX

[kenyonj]

Goal

Wire Copilot CLI into the "local sessions on issues" pipeline by letting a CLI session declare it's attached to a specific GitHub issue at session-create time, and surfacing that attachment on the issue header.

Tracking issue: github/planning-tracking#2952

Context

The spike (planning-tracking#2952) is converging on the AgentSessionStart hydro pipeline path (per the hydro-schemas#8634 pivot comment, discarding the MCP-request-telemetry approach).

What's already in flight in adjacent repos:

• copilot-mission-control#3311 — accepts ResourceType: "issue" on session create. Backend is ready to receive the new resource type. CI green, awaiting reviewers.
• github-ui#20800 — frontend gating for the CLI session deep-link on the issue header. Cloud-agent behavior preserved; CLI deep-link suppressed unless viewer is the session creator. CI green after lockfile fix.

Neither of those does anything user-visible until the CLI side starts attaching sessions to issues.

Scope

Three pieces, roughly in order:

1. Attach UX in the CLI

   • Detect or accept the target issue (e.g., gh copilot --issue OWNER/REPO#42, or auto-detect from current working context, or a slash-command in-session).
   • Resolve the issue's repo + numeric id.
   • Pass resource_type: "issue", resource_id, resource_number when creating the mission-control session (POST /agent_tasks/sessions or whatever the current create call is).

2. Session-lifecycle events carry the issue resource

   • Once a session is attached, AgentSessionStart / Finish / WaitingForUser events emitted by mission-control should already carry resource_type="issue" + resource_id (see the follow-up listed in copilot-mission-control#3311's body: "Wire the new resource type through publishSessionHydroEvent").
   • The CLI side just needs to ensure the session attachment is set early enough that the first event carries it.

3. In-session UX

   • When a session is attached to an issue, surface that in the CLI (a header pill, a status line, a confirmation). Detach UX too.

Out of scope

• Cloud-agent assignments, unaffected by this work.
• 3P agents (Claude Code, Codex, etc.), separate path, deliberately not lumped in here.
• Multi-issue attach (one session, multiple issues), defer until single-issue is shipped.

Open questions

• Attach trigger: explicit flag, auto-detect from gh context, or in-session command? Probably want at least the explicit flag for the first iteration, with auto-detect later.
• Pre-existing session attachment: if the user already has a session running and then wants to attach, do we allow re-attachment via session update, or require a new session? copilot-mission-control#3311 updates the Update path with a NOTE that Issue is not yet handled there; resolving that is a soft prereq.
• Cross-repo issues: what if the user attaches to an issue in a repo different from their current working dir? Allowed or rejected?

Dependencies

• Not blocked by copilot-mission-control#3311 merging, CLI work can begin against the draft. But the end-to-end test requires CLI auth flow silently swallows REST quota / rate-limit errors during token validation, surfaces them as 'Session was not created with authentication info or custom provider' #3311 to be merged.
• Likely needs a dotcom-side change to actually create an AgentAssignment row when an Issue-typed AgentSessionStart event arrives. (See discussion thread on planning-tracking#2952: HydroSweAgentJobStatusChangeJob is a notifier, not a creator; the existing creator job HydroCopilotAgentAssignmentLiveUpdateJob only handles the issue_created automation path, not "CLI attached to existing issue.")

Status

Draft issue. Not ready to start work until the CLI-attach trigger UX is agreed on. Filing now so the open-PR cluster has a CLI-side anchor.