Taskbar presence card stays at taskState 0 (spinner) when a turn ends via task_complete

[XuemeiPeng]

Describe the bug

On Windows, the taskbar App Task created by the taskbar-presence feature never leaves the "working" state when a turn ends through the task_complete tool (autopilot mode). The card keeps spinning indefinitely until the session unmounts or the CLI exits.

The 0 -> 1 state transition appears to be wired only to the session.idle event handler (the same handler that maps an aborted turn to state 3). Turns that terminate via task_complete do not appear to emit session.idle, so no handler fires and the task is orphaned at taskState: 0. dispose() on unmount ends up being the only thing that clears it.

Affected version

GitHub Copilot CLI 1.0.84

Steps to reproduce the behavior

1. Enable taskbar presence on Windows 11 (build 26100+) with package identity present (taskbarPresence on, TASKBAR_PRESENCE flag on).
2. Run a session in autopilot mode so the turn ends with the task_complete tool.
3. Watch the taskbar card after the final answer has rendered.
4. The card is still spinning, showing currentStep: "Working on your request".

Inspect %LOCALAPPDATA%\Packages\<PFN>\SystemAppData\AppTasks\tasks.json:

{
  "title": "GitHub Copilot CLI",
  "taskState": 0,
  "dataJson": { "data": {
    "completedSteps": ["...", "Task complete: <the final answer>"],
    "currentStep": "Working on your request"
  }}
}

The debug log shows the last state=0, template=steps write, then the turn ending with "reason": "task_complete", and no further state update:

[DEBUG] Taskbar presence: updated task {...} (state=0, template=steps)
        "reason": "task_complete"      <- turn ends here
        (no state=1 update is ever written)

A session in the same window that ended normally DID reach state=1, template=summary, so this is specific to the task_complete path.

Expected behavior

At the end of the turn the task should move to taskState: 1 with template: summary, matching the behavior of turns that end normally (which do transition correctly).

Suggested fix: drive the terminal state from the task_complete / turn-ended path as well, or emit session.idle on that path.

Additional context

• OS: Windows 11, build 26200; x86_64; Windows Terminal; PowerShell
• The taskbar-presence pipeline itself is healthy. copilot taskbar-selftest, run under package identity, passes every gate (isSupported, packageIdentity, iconUri, createOrUpdate, findAll, tasks.json) and reports "RESULT: tasks.json written - taskbar presence is working." Its own self-test task is created and removed cleanly, leaving only the genuinely stuck session card behind.

Two secondary papercuts in taskbar-selftest noticed while confirming the above:

1. When invoked through a path that does not carry package identity, it reports misleading failures (packageIdentity: none, createOrUpdate: no task created, findAll: 0 task(s)) rather than detecting the situation and telling you to relaunch through the packaged alias.
2. It always prints [FAIL] featureFlag: TASKBAR_PRESENCE disabled (its own output admits "an ExP assignment is not visible to this command") even when interactive sessions log rollout_flag_enabled=true. This reads as a genuine failure when it is not.

[DevGhub007]

Thanks for the detailed report — the tasks.json dump and the debug-log excerpt are really helpful. I've been tracing this in the runtime + CLI and I'm close, but I need a few specifics to pin the exact code path before proposing a fix.

What I've confirmed so far

• TaskbarTaskState.Running = 0, Completed = 1 — matches what you're seeing.
• The CLI taskbar hook drives the Completed/summary transition only from the session.idle event (not aborted). It does not currently key off task_complete at all.
• The runtime does emit session.idle when autopilot stops after task_complete — there's a regression test for exactly this ("stop autopilot continuation after task completion"), and that fix shipped in 1.0.82+, so 1.0.84 has it.

Because your log shows no state=1 write is ever emitted (not a state=1 that later gets overwritten), the most likely explanation is that session.idle isn't reaching the hook in your specific scenario — so I need to identify which branch of the stop/continuation path you're hitting.

Questions

1. How was the stuck session started? /autopilot <goal> (objective mode), --autopilot at launch, or a plain interactive prompt where the agent happened to call task_complete?
2. Concurrency at the time: was this a single session, or were there multiple in-process sessions (a foreground + one or more background sessions) in that same copilot.exe? You mention "a session in the same window that ended normally" — was that a separate tab/process, or a background session in the same process?
3. Was any other work active in that process when the stuck turn ended — a background session/agent still running, or a running shell command?
4. Decisive one: in the debug log around the stuck turn's end, is there a session.idle line after the "reason": "task_complete" turn-end? (If yes → CLI handler bug; if no → the runtime didn't emit idle on that path.)
5. Did the model call task_complete once, or was there any autopilot continuation/looping before it settled?

Logs / artifacts that would nail it

• The full debug log for the stuck turn from the last user.message through session end (feel free to redact content). Ideally captured with debug logging on:
  • Env: COPILOT_LOG_LEVEL=debug (and, if you have it enabled, the taskbar-presence debug log).
• The copilot taskbar-selftest output run under package identity (you said it passes — the raw text is still useful for the secondary papercuts below).
• A screenshot of the stuck hover card (spinner + "Working on your request") next to the taskbar, and — if easy — a short screen capture showing the final answer rendering while the card keeps spinning.
• The exact tasks.json you pasted is great; if you can grab it a second time ~30s after the turn ends (to confirm it stays at taskState: 0 and isn't a transient), that would help.

On the two taskbar-selftest papercuts

Both are reproducible and I can address them regardless of the main bug:

1. It reporting packageIdentity: none / createOrUpdate: no task created when invoked without package identity — I agree it should detect that and tell you to relaunch through the packaged alias.
2. The always-[FAIL] featureFlag: TASKBAR_PRESENCE disabled line when an ExP assignment isn't visible to the command — agreed this reads as a false failure.

If you can share (1)–(5) plus the full debug log, I can point at the exact branch and put up a fix. Thanks!