Feature request: A master session to manage Copilot App sessions

No files, tests, or entry points are named; begin by locating the existing session lifecycle, archive, workspace-cleanup, and app-permission areas described in the proposal. Treat the MVP acceptance criteria as the definition of done, including evidence-backed preview, exact-target approval, recoverable archive and restore, receipts, protected-session handling, and resumable batches.

Feature request: A master session to manage Copilot App sessions

Status: Design draft, not yet filed.

Summary

Add a persistent, app-level Session Manager: a master session that helps the user understand, organize, and clean up their existing Copilot App sessions across selected projects. The user can ask, "Find completed sessions in this project and help me archive them." The manager returns an evidence-backed shortlist, previews exactly what would change, and executes a user-approved batch.

The key capability is managing existing sessions, not just sessions the manager created. This must be an explicit, app-enforced permission, not a workaround around current parent/child restrictions.

Problem and observed evidence

Session creation is easy; managing the accumulated sessions is not. Users must distinguish active work, completed PRs, abandoned attempts, reusable investigations, and automation runs before deciding what can be archived.

In a real cleanup attempt on September 24, 2026:

• One repository had 325 visible project sessions, including 306 reported idle at the time of inspection.
• Cached app metadata identified 10 idle sessions with merged PRs. Checking linked PRs directly on GitHub identified 24. Cached state alone would have missed 14 candidates.
• The user approved archiving the listed sessions, but the available archive tool only supported sessions created by the current conversation. The agent could produce the list but could not complete the operation.
• Those 24 sessions had not yet been audited for uncommitted changes or unfinished follow-up work. Idle plus merged is a shortlist, not proof that archiving is safe.

The missing experience is a supported path from inventory -> evidence -> approval -> action -> receipt.

User experience

Expose Manage sessions at app level. It opens one reusable Session Manager conversation alongside a structured session table; it does not create another repository worktree for every cleanup.

Example request:

Focus on this project. Show idle sessions whose PRs have merged. Keep anything with local changes, open follow-up work, or an attached schedule.

The manager offers filters for project, last meaningful activity, runtime state, live PR state, automation origin, and protection status. Every row links to the original session.

Session | Activity | PR | Local work | Recommendation -- | -- | -- | -- | -- Fix request timeout | Idle | Merged, checked now | Clean and recoverable | Ready to archive Improve diagnostics | Idle | Merged, checked now | Two modified files | Preserve local work Follow-up investigation | Idle | Open | Clean | Keep Daily health monitor | Idle | None | Attached schedule | Protected Remote debugging | Unknown | Unknown | Host unavailable | Needs review

Execution must acquire the app's lifecycle guard so a session cannot start, be edited, or join a merge between approval and archiving. External workspace changes must also be accounted for: worktree removal must use a recoverable cleanup mechanism, not rely solely on a previous status scan. If recovery cannot be guaranteed, preserve the worktree and report incomplete cleanup.

Changes after preview invalidate the affected item's approval. Do not substitute a different session, expand a cascade, or turn the approved list into a dynamic "all matching sessions" query.

Archive each session as a recoverable transaction: preserve the required history, metadata, and recovery record before releasing workspace resources. A crash or cleanup failure must not leave successful-looking results with lost data. The lifecycle/cleanup implementation needs a feasibility review before promising fully automatic worktree removal.

Batches are resumable and idempotent. Retry only unfinished items, preserve earlier receipts, and isolate failures. Cancellation stops new items and lets an in-flight transaction reach a safe boundary.

Recovery and audit

Archive is not permanent deletion. Preserve conversation history, original project identity, PR/issue links, artifact references, and the archive receipt. Explicitly state which workspace data is recoverable and from where.

Maintain a user-visible audit trail with the approval, actor, time, target IDs, eligibility evidence, results, and restore outcomes. Do not include source contents, secrets, or full transcripts in aggregate product telemetry.

No permanent history deletion is included in the MVP.

Keeping the backlog manageable

Add saved views such as Merged PR + idle, Needs preservation, Waiting for me, and Older sessions without PRs.

Offer a periodic cleanup review that proposes a batch but does not execute it without approval. Later, consider explicit per-workflow retention policies for completed automation runs, separate from the workflow's schedule and enabled state.

Do not assume automations caused an existing backlog. The observed inventory included recurring workflows, but the inspection did not establish that their historical runs were accumulating in the visible session list.

MVP scope and acceptance criteria

The MVP includes a persistent manager, scoped access to existing sessions, an evidence-backed table, bulk archive preview/approval, protected-session handling, receipts, and restoration. It does not include deleting history, merging PRs, changing code, stopping active sessions, changing automation schedules, or organization-wide administration.

1. A user can manage an authorized session created before the manager existed, without reparenting it.
2. Live PR refresh finds merged candidates even when app metadata says open or draft.
3. Modified files, unsaved drafts, unpreserved local commits, protected sessions, and unavailable hosts cannot be silently included.
4. Approval names exact targets and consequences; a newly matching session is never added automatically.
5. A session becoming active or changing after preview is skipped with an explicit reason.
6. A failure halfway through a batch produces accurate per-item results and can be resumed without duplicate actions.
7. Archived history remains searchable; restoration reports honestly which workspace state is recoverable.
8. A test inventory of 500 sessions and a 100-item batch works through pagination and bounded concurrency without requiring every transcript in model context. These are proposed acceptance sizes, not measured performance claims.
9. Every successful archive action has a matching native approval and durable receipt; unauthorized cross-project requests are rejected by the backend.

Suggested delivery sequence

Phase 1: Read-only inventory, live evidence, protection reasons, and a useful cleanup preview.

Phase 2: The explicit existing-session management grant, native bulk approval, guarded archive execution, receipts, and recovery. This is the minimum release that resolves the original feature request end to end.

Phase 3: Saved cleanup views, periodic review, and separately approved automation-run retention.

Product principle: Make it easy to clean up hundreds of sessions without making it easy to lose one important piece of work.