Kickoff prompt silently dropped when a new session is created — worktree provisioned but agent never receives the message

[russrimm]

Describe the bug

When a new session is created from the app with an initial prompt, the git worktree, branch, and CLI session are provisioned successfully, but the kickoff prompt is never delivered to the agent. The session sits idle forever with no assistant response, and the prompt text is lost — it is not persisted in the session event log, the local session store, or the cloud session store, so it cannot be recovered.

From the user's perspective a workstream appears to have been created, but none of the instructions they gave were received or performed. This happened at least 6 times in a single day on one machine.

Affected version

GitHub Copilot CLI 1.0.79-5.

Steps to reproduce the behavior

I have not found a deterministic trigger, but the failure has a consistent signature in the process logs. For an affected session, the only inbound requests are session.create, session.resume, and session.getMessages — no turn/prompt request ever arrives:

21:09:50  Received session.create request
21:09:55  Received session.resume request   <- x3 within 0.4s
21:09:56  Received session.resume request
21:09:56  Received session.resume request
21:09:56  Received session.getMessages request
21:10:04  Received session.getMessages request
(nothing further — no prompt ever delivered)

A second affected session shows the identical pattern, and was later torn down without ever running a turn:

21:05:29  Received session.create request     (branch russrimm-urban-waffle)
21:05:33  Received session.resume request   <- x3 within 0.4s
21:05:33  Received session.resume request
21:05:33  Received session.resume request
21:05:34  Received session.getMessages request
21:05:58  Received session.getMessages request
21:18:34  Received session.destroy request    <- never received a prompt

The corresponding session-state/<id>/events.jsonl contains only session.start, session.permissions_changed, and session.remote_steerable_changed — no user.message event. Some affected sessions have no session-state directory at all.

Two observations that may be related:

1. Triple session.resume inside ~0.4s. Both failed sessions show session.resume fired three times in rapid succession immediately after session.create. This looks like a race during session initialization.

2. Kickoff prompts appear to be queued, and the queue sometimes never flushes. Sessions that did work the same day showed very long delays between creation and their first turn:

   Session	Created	First turn	Delay
   0d336342	20:34:41	20:47:36	~13 min
   70c938fc	20:42:54	20:52:39	~10 min

   Session startup itself is slow — MCP servers finish loading 12–27s after session.resume. If the prompt is dispatched during that initialization window without a retry or acknowledgement, it appears to be dropped.

Expected behavior

The kickoff prompt should be delivered reliably, and never silently lost. Specifically:

• Prompt delivery should be acknowledged and retried until the session accepts it, rather than fire-and-forget during session initialization.
• The prompt text should be persisted at enqueue time (before delivery is attempted), so it survives a failed handoff and can be replayed or at minimum shown to the user for re-submission.
• If delivery ultimately fails, the session should surface a visible error instead of sitting silently idle, so the user knows to resend rather than assuming work is underway.

Additional context

• Operating system: Windows 11 Enterprise 10.0.26200.0
• CPU architecture: AMD64
• Client: client_name: github/autopilot (sessions created via the app, each with its own git worktree)
• Sessions observed with zero turns on 2026-08-09: 81740d62, 6cd2559d, 39906778, c8b74c18, 2f8a8518, plus one more that was created empty and only became usable when the user manually typed into it.
• Config note (possibly contributing to slow startup): duplicate MCP server registrations across plugins are logged as errors at startup — playwright, microsoft-learn, and workiq are each defined by two different plugins.

Secondary bug — orphaned worktree left on disk. When one of these empty sessions was destroyed, cleanup was only partial: the worktree's .git file was removed and git worktree list marked the entry prunable, but the working directory (including node_modules) was left behind on disk. It had to be removed manually with git worktree prune plus a forced directory delete. Sessions that are torn down should clean up their worktree fully, or leave it fully intact — not half-removed.