feat(desktop): support referencing another session from the composer

[ARE404]

Problem

Maka currently supports @ references for workspace files and structured QuoteRef excerpts selected from the current transcript, but there is no user-facing way to reference another session as context.

When useful context already exists in a previous session, users have to manually copy excerpts, repeat the background, or branch from an earlier Turn. Branching is useful for continuing the same history, but it does not cover the case where a new or existing session needs context from a separate session.

Desired outcome

Allow users to explicitly reference another session from the composer, with a clear chip/preview and deterministic context semantics. For example, the composer could expose sessions through an @ picker alongside files.

The design should make clear:

• whether the reference captures a snapshot or resolves live;
• how much session content is included and how it fits within the model context window;
• how archived, deleted, or inaccessible sessions behave;
• how provenance is shown to the user and preserved in stored messages.

I am happy to work on this feature if the maintainers agree with the direction.

Alternatives or workarounds

Today, users can manually copy text into the composer, select individual transcript excerpts as QuoteRefs, or branch from a Turn. These approaches either lose session-level provenance, require manual curation, or create a new continuation rather than referencing independent context.

[testikun]

This was generated by AI during triage.

I would like to work on this issue. I will first align the design with maintainers in the discussion below, then implement it in reviewable slices.

The initial scope I propose is same-host cross-session discovery, read, and messaging. Cross-host access and implicit full-history injection would remain out of scope for the first iteration.

中文摘要

我希望认领这个 issue。下面先提交技术方案，与维护者确认方向后再开始实现，并拆成可独立审查的切片。

第一版建议只支持同一 Runtime Host 内的跨 Session 发现、读取和发送消息；暂不包含跨 Host 访问，也不默认注入目标 Session 的完整历史。

[testikun]

This was generated by AI during triage.

Technical discussion: cross-session collaboration

The original issue describes a Composer flow where a user selects @Session, sees a reference chip, and sends a bounded snapshot of that Session as part of the current model request. This is a useful UI entry point for borrowing a short piece of context, but I do not recommend making implicit snapshot injection the core cross-session protocol.

Why the original snapshot-first approach is risky

1. Context growth is easy to underestimate. A bounded snapshot can still be repeated across turns, combined with multiple Session references, or added when the current turn is already near its context limit. Long tool output and duplicated summaries can trigger extra compaction, latency, and cost. A very small limit risks dropping the only useful conclusion; a larger limit competes with the current task's context.
2. A snapshot becomes stale. The source Session may continue working after the snapshot is captured. The receiving model needs to know when it was read, whether it was truncated, and whether it represents a final result or an intermediate state.
3. The action semantics are ambiguous. “Give me background from Session A” is different from “send this proposal to Session A and ask it to review it.” Injecting text into the current prompt cannot express delivery, acknowledgement, queueing, or a response from the target Session.
4. The data boundary is difficult to make safe by default. Session history can include tool arguments and outputs, local paths, permission events, diagnostics, or other sensitive material. Copying a broad history into another model request risks leaking data and mixing old instructions with the current user's intent.
5. Failures are hidden inside the current request. If the source is unavailable or reading times out, the user should be able to distinguish a read failure from a provider failure and retry the read without rerunning the whole turn.

Recommended protocol

Keep @Session as the discoverable Composer entry point, but make the user choose an explicit operation:

@Session
├── Read / 读取
└── Send message / 发送消息

1. task_list

Return only sessions the caller can access on the current Runtime Host, with minimal metadata (sessionId, name, status, and updatedAt). Listing must not scan or inject full history.

2. task_read

Read another Session without modifying or waking it. The default response should contain a redacted summary and recent user/assistant items, with a bounded size and a continuation cursor for older content:

 task_read(sessionId, {
   mode: 'summary' | 'recent' | 'full',
   cursor?: string,
   limit?: number,
 })

The result should include the source Session identity, read timestamp, hasMore, and truncated. Credentials, tool parameters, internal system events, and other non-shareable fields must be filtered before the data can reach the current model. The current turn should only receive the page explicitly requested; it must not receive the complete transcript automatically.

3. task_message

Send an explicit message to another Session. The payload may contain text/Markdown and, where permitted, a workspace-file reference; it must not copy the target history or inherit its tools, credentials, or sandbox:

 task_message(sessionId, {
   text?: string,
   attachments?: [{ type: 'workspace_file', path: string }],
 })

Return a message ID and an explicit status such as queued, delivered, or failed. If the target is busy, queue the message; if it is unavailable or rejects the message, surface a stable, actionable error. This covers requests such as “tell Session A about the architecture.md we just wrote” or “ask Session A to check whether this proposal conflicts with its previous work.”

Where snapshots still fit

Snapshots should remain an opt-in convenience built on top of task_read: read one page, let the user select a short excerpt, and insert that excerpt into the Composer with source Session, timestamp, and truncation provenance. This preserves the convenient chip interaction without making every future request re-read and re-inject the source Session.

When the user actually needs the complete context, use an explicit fork/resume style operation instead of silently copying history. When the user needs collaboration, use task_message; when the user needs comparison or background, use paginated task_read.

Reviewable implementation slices

• Slice A — discovery and read: reuse the existing session listing/turn access where possible, add a typed read contract, filtering, size limits, cursors, and read-only regression tests. Verify that reading does not start a provider request, tool call, or state transition in the target Session.
• Slice B — message: add the same-host message queue, delivery states, message IDs, permission checks, and tests for queued, delivered, unavailable, rejected, and retry cases.
• Later, only if needed: explicit fork/resume, cross-host sessions, and the opt-in excerpt/QuoteRef shortcut.

Acceptance criteria

• Reading a long Session does not linearly inject its complete history into the current model request.
• Default reads are bounded and can continue with a cursor.
• Reads are side-effect free for the target Session.
• Messages do not transfer history, tools, credentials, or sandbox permissions.
• UI clearly distinguishes material read from a message delivered to another Session.
• Source, target, actor, timestamp, truncation, and delivery status are auditable.

中文摘要

原 issue 的“@Session + 引用 chip + 有界快照注入”适合作为短内容引用的交互入口，但不建议作为跨 Session 的核心协议。即使快照有上限，也可能在多轮、多 Session 引用或上下文接近上限时累计膨胀，带来 token、延迟和 compaction 成本；快照还可能过时，且容易混入工具参数、路径、权限事件等敏感内容。更重要的是，它无法区分“读取背景”和“向另一个 Session 发消息请求协作”。

建议把能力拆成 task_list、task_read 和 task_message：

• task_list 只发现当前 Host 上有权限访问的 Session 元数据；
• task_read 默认返回脱敏摘要和最近内容，支持大小限制与 cursor 分页，不唤醒、不修改目标 Session；
• task_message 显式发送文字、Markdown 或工作区文件引用，返回 queued / delivered / failed 状态，不复制目标历史，也不继承目标权限。

快照保留为 task_read 之后的显式短摘录：用户选择一小段内容后再插入 Composer，并标记来源、时间和截断状态。需要完整上下文时使用显式 fork/resume，需要协作时使用 message，需要比较历史时使用分页 read。

实现建议先拆两个可审查切片：Slice A 做发现与读取，Slice B 做消息投递；跨 Host、完整历史导入和 fork/resume 放到后续范围。

I would appreciate maintainer feedback on this boundary before implementation, especially whether same-host task_read and task_message should be accepted as the first slice for #4309.

[ARE404]

Thanks for the detailed proposal. I haven't thought through the broader cross-session collaboration model that far yet. Are you envisioning something similar to pi's intercom, where sessions can communicate and send messages to each other?

My current idea for this issue is much narrower: simply reference another session from the Composer and bring a bounded snapshot or excerpt into the current context, without messaging or waking the referenced session.

[testikun]

This was generated by AI during triage.

Thanks for clarifying, @ARE404. My previous proposal described a broader cross-session collaboration model, including messaging between sessions. For #4309, I agree that we should keep the scope narrow and focus on a read-only Composer reference.

The implementation would be:

• Add other accessible sessions to the Composer @Session picker.
• Represent the selected session as a reference chip.
• Resolve one bounded snapshot or an explicitly selected excerpt when the current message is sent.
• Inject only that bounded content into the current context, with source-session, read-time, and truncation metadata.
• Filter credentials, tool arguments, system events, and other non-shareable data before injection.
• Do not message, wake, modify, or inherit permissions from the referenced session.
• Keep the reference as a one-time snapshot; later turns will not silently re-read or refresh it.
• Make source-read failures explicit and actionable, without turning them into provider or target-session requests.

The first implementation slice would therefore cover the session picker, a same-host read-only snapshot operation, the QuoteRef/model-history integration, and regression tests for access scope, size limits, truncation, provenance, and the fact that reading does not start work in the referenced session.

Pi-style intercom, Codex-style task messaging, live references, full-history import, and fork/resume semantics would be separate future work rather than part of this issue.

中文摘要

感谢澄清。之前的方案确实扩展到了跨 Session 消息协作。对于 #4309，我同意收窄范围，只实现 Composer 中的只读 Session 引用：

• 在 @Session 选择器中列出当前用户有权限访问的其他 Session；
• 选择后显示引用 chip；
• 当前消息发送时读取一次有界快照或用户明确选择的摘录；
• 只将这段有限内容注入当前上下文，并附带来源 Session、读取时间和截断信息；
• 注入前过滤凭据、工具参数、系统事件和其他不可共享数据；
• 不向目标 Session 发消息、不唤醒、不修改，也不继承目标权限；
• 该引用是一次性快照，后续轮次不会隐式重新读取或刷新；
• 读取失败时给出明确、可操作的错误，不触发目标 Session 的模型请求。

第一阶段只实现 Session 选择器、同 Host 的只读快照读取、QuoteRef/模型历史接入以及相关回归测试。Pi intercom、Codex 式任务消息、实时引用、完整历史导入和 fork/resume 暂不属于这个 issue。

If this matches the intended scope, I will proceed with this narrower implementation.

[ARE404]

Yes, this matches the intended scope. Please go ahead and take ownership of the implementation. Thanks!

We can consider a pi-style intercom capability separately as future work.