macOS 1.1.22: sessions fail to report completion, queueing fails, and work appears stalled

Start with the get_sessions_status evidence for local project sessions on macOS app 1.1.22, then trace the submit-and-queue workflow described in the reproduction steps. Done means sessions report completion accurately, queued follow-up work progresses, and blocked execution or delivery exposes a recoverable error instead of remaining indefinitely busy.

Short summary

This is a workflow-blocking completion and queueing problem, not just a cosmetic activity-indicator bug.

Across my current sessions, none appear to report completion correctly. Queuing does not work, and work does not seem to progress. Sessions continue to look like they are working even when they have been idle for a long time.

I have been noticing this for the past couple of days. The initial report understated the impact by focusing on the stale working indicator.

Affected version or release

GitHub Copilot desktop app 1.1.22 (bundle build 1.1.22), confirmed from the running app's installed bundle metadata when this issue was filed.

This is the observed version, not a confirmed first affected release.

Installation context

• macOS 26.7, build 25G229.
• Local desktop app.
• The originally inspected example is a local, branch-backed project session in autopilot mode.

What happened?

Broader user-observed impact, clarified on 2026-09-18 at 14:03 UTC:

• None of my current sessions appear to report completion correctly.
• Queuing is not functioning as expected.
• Work does not seem to progress, rather than merely progressing behind an incorrect indicator.
• This blocks normal use of sessions and queued follow-up work, and makes it impossible to reliably tell what has finished.

Independently collected status evidence from earlier the same day:

A read-only get_sessions_status snapshot returned the following sanitized fields for an affected session:

{
  "activity": {
    "status": "busy"
  },
  "is_running": false,
  "mode": "autopilot",
  "awaiting_user_input": false,
  "awaiting_plan_approval": false
}

That snapshot contained two sessions with both activity.status == "busy" and is_running == false. The inspected example also showed this combination in earlier snapshots during the same investigation.

Two is the number exhibiting this exact status combination in that snapshot, not a count limiting the broader completion/queueing problem to two sessions.

There is no pending user-input or plan-approval request reported for the inspected session. These diagnostics confirm the exposed status mismatch. The broader completion, queueing, and apparent work-stalling symptoms above are my observed experience; an end-to-end queue-delivery trace has not yet been captured, and a source-level cause is not established.

Steps to reproduce

Observed workflow; the exact trigger and a deterministic minimal reproduction are not yet known:

1. Use local project sessions and submit work.
2. Queue follow-up work.
3. Observe that sessions do not correctly report completion, queueing does not work as expected, and work does not appear to advance. Sessions can continue to look active for a long time.
4. Inspect get_sessions_status: an affected example reports busy while is_running is false.

Expected behavior

• Sessions should accurately report when work completes and transition out of the working state.
• Queued follow-up work should be dispatched and make progress when the session becomes available.
• If execution or queue delivery is blocked or has failed, expose that condition and a recoverable error instead of indefinitely appearing to work.
• The UI and exposed session status should consistently distinguish active work, completed/idle sessions, and sessions waiting for input.

Additional context

• The original statement that queueing failure had not been reproduced is superseded by the broader user-observed failure described above.
• No workaround has been verified for this occurrence.
• No manual Stop, queue clearing, app restart, runtime termination, or database edits were performed during the original read-only diagnostic checks.
• Permanent message loss has not been established.
• Session names and IDs, repository names, local paths, prompts, source code, and raw logs are intentionally omitted.

Related existing reports:

• #3525: inactive sessions remain Running and queued messages can get stuck.
• #3650: macOS session remains Running after the model returns an answer.
• #1560: sidebar spinner continues after session tasks are completed.

Please triage this as a completion/queueing/work-progression failure, not only a visual status issue. This report adds macOS / app 1.1.22 evidence with is_running: false; it does not assume all related reports share the same root cause.