filter/scope session tabs & resume list by repository/solution
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
首先閱讀 open-sessions-state.json，並追蹤 session store 資料如何傳遞到分頁清單、/resume 選擇器和 /session 選擇器。確認工作目錄或 repository 在 session store 中是如何表示的。當 sessions 能夠持久保存該關聯，且選擇器預設使用目前的 repository，同時仍提供所有 sessions 檢視畫面時，即視為完成。
由索引模型根據 Issue 內容生成。
描述
Describe the feature or problem you'd like to solve
Currently, the session tab list and /resume picker show all sessions across every repo/solution I've worked in, sorted purely by recency. There's no per-repository scoping — open-sessions-state.json only stores openedAt / working / refreshedAt , no cwd / repository field, so the UI has nothing to filter on even if it wanted to. This becomes a real problem when working across multiple unrelated solutions on the same machine (e.g. a Blazor support app vs. an NLQuery/report agent vs. WCF services): sessions from completely different codebases end up mixed together in the tab list, making it hard to find the session relevant to the solution I currently have open.
Proposed solution
persist the working directory/repository per session (the data already exists in the session store itself, just not surfaced in open-sessions-state.json ), and let the tab list / /resume / /session picker filter or group by "sessions for this repo" by default, with an option to show all.
Example prompts or workflows
- "Resume an old session for this project" — I open solution X, type /resume , and only see sessions that were ever started in X, instead of scrolling through dozens of sessions from unrelated projects to find the right one.
- Context-switching between multiple codebases on one machine — I work on a Blazor support app, a WCF service layer, and an NLQuery reporting agent in turn. With per-repo filtering, each tab list stays scoped to that project, so I never accidentally continue a session that was actually about a completely different codebase.
- "Where did I leave off on this project?" — After being away from a specific solution for a few days, I open that folder and want to instantly see only the sessions relevant to it, sorted by recency — not my entire cross-project history mixed together.
- Cleaning up/archiving per project — With repo scoping, I can more easily bulk-clean old sessions from a finished project without risking accidentally losing active sessions from a different project in the process.
- Onboarding/handover — If I want to show someone "all Copilot sessions done on this project," a repo-filtered list is immediately usable as an overview, instead of first manually filtering out noise from other projects.
Additional context
No response
- 主要語言
- Shell
- 星號
- 11.2k
- 分支
- 1.9k
- 平均合併
- 17 小時 6 分鐘
- 30 天內合併 PR
- 5
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
github/copilot-cli 的其他 Issue
-
triage
難度 1/5 1 小時以內 新手友好度 88/100
github/copilot-cli#4963 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 75/100
github/copilot-cli#4932 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 78/100
github/copilot-cli#4909 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 76/100
github/copilot-cli#4906 ·
維護者通常 1 天內回覆
-
triage
難度 2/5 1-3 小時 新手友好度 72/100
github/copilot-cli#4848 ·
維護者通常 1 天內回覆
查看 github/copilot-cli 的全部 Issue
相似的 Issue
-
out-of-date
難度 1/5 1 小時以內 新手友好度 82/100
CachyOS/CachyOS-PKGBUILDS#1917 ·
維護者通常 1 天內回覆
-
package-update
難度 2/5 1-3 小時 新手友好度 78/100
-
bug needs triage
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 82/100
EmbarkStudios/cargo-about#323 ·
-
難度 2/5 1-3 小時 新手友好度 78/100
vllm-project/vllm-metal#841 ·
維護者通常 1 天內回覆