Repository navigation
Native Copilot CLI chat transcript support #1574
Description
Problem
Copilot CLI panes currently fall back to terminal scrollback rather than a structured conversation. On main at ee2daec0, Copilot is absent from SUPPORTED_AGENT_KINDS and resolveTranscript has no Copilot reader, despite existing detection, icon and usage-meter support.
Proposal
Would you accept a narrowly scoped native Copilot CLI chat transcript adapter?
- Read the pane's explicitly reported Copilot session from its native
session-state/<session-id>/events.jsonlstore, without guessing from cwd or modification time. - Map user/assistant messages and tool activity onto the existing conversation contract and chat UI.
- Reuse the existing bounded history pagination, transcript monitoring and PTY message-send path.
- Respect the pane's custom Copilot home, refuse ambiguous/missing bindings, and test resume/session switches and simultaneous panes.
- Leave approvals, interactive menus, session browsing and new UI concepts out of this initial scope; users continue to handle those in Terminal.
The persisted event format and session binding need validation against an actual Copilot CLI version, not only SDK types. Parser, resolver, HTTP-contract and isolated browser tests would accompany the adapter.
Where it exists today
Copilot CLI already displays its own saved chat in its TUI. This proposal mirrors that history in the same Chat lens that Herdr Web UI uses for Claude Code, Codex and Hermes; it does not introduce a separate chat product or agent API.
Workarounds and alternatives
Use the Terminal view today. The usage meter and icon do not provide structured conversation history.
I am evaluating this in a personal fork for my own use. I understand upstream's feature-approval policy and will not open an upstream implementation PR without maintainer agreement on the scope above.
Activity
YuuuXie commentedon Oct 21, 2026
A runtime spike found an important dependency for the proposed exact session binding.
With Herdr 0.9.3 and Copilot CLI 1.0.102-1 in an isolated test daemon/home, the official
SessionStarthook correctly reported the first session UUID. After interactive/new,/clear, and/resume, Copilot persisted the new/current UUID in successfulhook.start/hook.endevents, but bothagent.getand the snapshot retained the first UUID. The process PID and launch argv stayed unchanged throughout.The 0.9.3 hook emits a fresh
seqbut does not forward the hook input's lifecyclesource. More importantly,session_report_allows_session_replacementinsrc/terminal/state.rshas no Copilot case. A separate owned API probe using a fresh greater sequence andsession_start_source=newalso returned success without replacing the session ID.References:
Consequently, checking that the reported file exists and its
session.start.data.sessionIdmatches is insufficient: it still matches the old conversation after a switch. I am evaluating current-process held-file evidence as a read-only alternative; I will not use cwd/newest-session guessing or assume launch argv tracks interactive switches. No upstream implementation PR is being opened while approval and this binding question remain unresolved.YuuuXie commentedon Oct 22, 2026
I have separated the small launcher bug fix from native transcript support:
Both branches are independently based on upstream
mainatd5a35b7a, with current upstream conflicts resolved. The native reader remains narrowly scoped:The independent chat branch passes full fast checks (6,076 unit tests, 0 failed, 12 existing skips), its native HTTP contract, and an owned-fixture browser check covering native rendering, tool output, appended history, desktop/mobile layout, and composer-to-PTY delivery. The fixture does not invoke a real model and uses isolated configuration. Full integration/browser lanes and native Windows install checks have not been run locally.
Would you accept an upstream PR with this scope and the documented Linux/session-switch limitations? I will continue to wait for maintainer agreement before submitting the chat implementation upstream.
YuuuXie commentedon Oct 22, 2026
Update to my earlier plan to wait before submitting: I have now opened #1652 so the proposed scope can be evaluated against the working implementation.
The PR explicitly states that maintainer agreement on this issue is still pending, acknowledges CONTRIBUTING.md, and is fine to close if the feature or scope is not wanted. This supersedes my earlier statements that I would wait before opening the implementation PR; it does not imply that approval has been granted.
It also references #1442 as a similar native-transcript integration into the existing conversation contract and chat UI, not as an approved precedent or a dependency. The Copilot-specific session identity safeguards and Linux/session-switch limitations are documented in the PR.
The independent launcher-only fix remains #1650. No additional implementation changes were made for this submission; #1652 uses the same independently verified native-chat branch.
fix(agents): offer installed Copilot in new-session menus (#1650)
feat(chat): read native Copilot CLI transcripts (#1652)
devswha commentedon Oct 27, 2026
Closing: native Copilot CLI chat landed in #1652 (5254f26, thanks @YuuuXie).
resolveTranscriptinserver/conversation.tsroutes a Copilot pane tocopilotTranscriptPath, and the reader isserver/copilot-store.ts; #1650 (c952eb5) offers an installed Copilot in the new-session menus. Follow-ups are tracked on their own: command completion in #1953, and keeping the history on a failed refresh in #2066 (open PR #2068).