Summary
The global Up next panel (cross-session inbox of assigned PRs / issues) currently only surfaces GitHub items. For projects backed by Azure DevOps repos — which the app already supports as projects — Up next is empty. Requesting that assigned ADO work items appear alongside GitHub items in the same panel. (Active ADO PRs would be a natural extension once work items land.)
Repro
Preconditions: the bundled ado-mcp server is authenticated against an Azure DevOps organisation, and the signed-in identity has at least one assigned open work item.
- Create a project in this Copilot CLI desktop app pointing at one or more Azure DevOps Git repos (no GitHub remote).
- Open the global Up next panel.
- Expected: assigned ADO work items appear.
- Actual: Up next is empty for that project. The project metadata exposed to the agent shows the GitHub repo field as unresolved for ADO-backed repos, which appears to leave the existing inbox path without a provider to query.
Proposed shape
- Per-project optional config: one ADO org + project + WIQL query. Suggested default:
[System.AssignedTo] = @Me AND [System.State] NOT IN ('Closed','Removed','Done','Completed') — treat as a starting default; ADO states are process-dependent so users should be able to override.
- Auth: reuse the ADO token already accepted by the bundled
ado-mcp server. No new auth surface.
- Render inline in Up next with a small provider badge so users can tell GitHub items from ADO items.
Active ADO PRs (author / reviewer) and multi-source / multi-org support are natural follow-ups, out of scope for this ask.
Workaround I'm running today
A per-project scheduled workflow queries my ADO queue via ado-mcp and renders an inbox widget inside a session — useful but session-scoped, so the global Up next stays empty.
Related (adjacent symptoms of non-GitHub project gaps — not claiming shared root cause)
Environment
- Copilot CLI v1.0.62, macOS / Tauri desktop
- Bundled
ado-mcp server, authenticated against an Azure DevOps organisation
Summary
The global Up next panel (cross-session inbox of assigned PRs / issues) currently only surfaces GitHub items. For projects backed by Azure DevOps repos — which the app already supports as projects — Up next is empty. Requesting that assigned ADO work items appear alongside GitHub items in the same panel. (Active ADO PRs would be a natural extension once work items land.)
Repro
Preconditions: the bundled
ado-mcpserver is authenticated against an Azure DevOps organisation, and the signed-in identity has at least one assigned open work item.Proposed shape
[System.AssignedTo] = @Me AND [System.State] NOT IN ('Closed','Removed','Done','Completed')— treat as a starting default; ADO states are process-dependent so users should be able to override.ado-mcpserver. No new auth surface.Active ADO PRs (author / reviewer) and multi-source / multi-org support are natural follow-ups, out of scope for this ask.
Workaround I'm running today
A per-project scheduled workflow queries my ADO queue via
ado-mcpand renders aninboxwidget inside a session — useful but session-scoped, so the global Up next stays empty.Related (adjacent symptoms of non-GitHub project gaps — not claiming shared root cause)
store_memoryfails when origin is not ongithub.com/memory"Manage stored memories" link 404s for non-GitHub reposEnvironment
ado-mcpserver, authenticated against an Azure DevOps organisation