[Tracking] Resource-scoped Runtime Host sharing and collaboration

[M4n5ter]

English

Problem

An authenticated remote Runtime Host Client currently has owner-like access. The Host cannot safely let another person read or participate in selected Sessions without also exposing unrelated Sessions, Projects, settings, credential stores, filesystem catalogs, diagnostics, or execution authority.

Connectivity and resource authorization are independent. Session sharing must work over existing TLS and SSH connections as well as future peer connectivity, and joining a network must not itself grant access.

This issue supersedes the sharing and collaboration scope of #3801. Application-scoped peer connectivity is tracked independently in #3842.

Desired outcome

Runtime Host supports independently authenticated Guest principals while remaining the sole authority for:

• which Sessions a principal can discover or observe;
• which intents a principal may submit;
• which actions require Owner approval;
• immediate revocation and subscription removal;
• attribution of accepted actions and durable decisions.

The initial collaboration milestone includes explicit Session observation and approval-mediated Turn contribution. Observation is the first implementation slice, not the product endpoint. The milestone is complete only when a Guest can observe a shared Session, propose an exact Turn, have the Host and Owner admit it under durable authority, and observe the result.

Shared Session content contract

Sharing an existing Session means that the Owner explicitly authorizes the Guest to read its complete user-visible canonical Session content, both historical and live while the grant remains active.

This includes content visible in the Session experience, such as:

• user and assistant messages;
• user-visible reasoning or thinking projections;
• tool names, arguments, status, stdout, stderr, and results;
• attachments or references that became part of the user-visible Session projection;
• future content of the same kinds emitted while the Guest retains access.

If this content already contains an absolute path, pasted token, credential, file content, or another secret, the Guest can see it. The Host cannot reliably classify arbitrary text after the fact or remove sensitive strings without changing meaning. The first milestone therefore performs no share-time semantic redaction and makes no promise that secrets embedded in granted Session content are hidden.

Content that was never part of the user-visible canonical Session projection remains private, including hidden model reasoning, system prompts, raw provider requests, internal Runtime state, and Client-local drafts or presentation state.

Host-private structured state

A Session grant does not expose unrelated or Host-private structured state. The Host filters it before projection rather than relying on a Client to hide it.

Examples include:

• workspace.hostCwd and other Host path metadata outside user-visible Session content;
• unrelated Session identifiers, titles, or counts;
• Project catalogs and filesystem discovery;
• Host settings, credential stores, and provider configuration;
• unrelated interactions, usage, diagnostics, and environment information.

Unknown and unauthorized resources should normally have the same external result.

Informed sharing

Before granting Session observation, the Owner must be told accurately that:

• the Guest receives the complete existing user-visible Session history;
• new user-visible live content remains readable while the grant is active;
• paths, file contents, credentials, or secrets already embedded in that content are not automatically hidden;
• revocation stops future access but cannot retract content the Guest already read or copied.

A preview may help the Owner inspect the Session, for example by showing its time range, message and tool-call counts, and recent content. It must not claim to have detected all sensitive information.

Architecture boundary

Connectivity provides an authenticated transport stream; whether that stream is encrypted depends on the selected transport. Connectivity grants no application authority.

The target Runtime Host owns Guest principal kinds, credentials, resource grants, access requests, revocation, and projection filtering. Authorization is evaluated for every request, subscription, and canonical rebuild.

Connectivity
  TLS / SSH / acknowledged plaintext / peer connectivity
       │ authenticated connection
       ▼
Runtime Host Access Authority
       │ authorized intent and projection
       ▼
Session / Interaction domains

Plaintext transport contract

Acknowledged plaintext remains an explicitly insecure authenticated transport. It may carry collaboration traffic only when the Host was started with --allow-insecure-remote and the Guest Client profile separately persists the user's risk acknowledgement.

Plaintext sends the Guest credential, complete shared Session content, and Turn requests without encryption. A third party able to observe the network may capture them. A collaboration invitation must never create a plaintext profile automatically, change an existing profile to plaintext, or downgrade a failed secure connection to plaintext.

This transport choice does not change resource authority: the Host applies the same principal, grant, Access Request, attribution, and revocation rules after authentication.

Invitation authority boundary

A collaboration invitation creates a restricted Guest principal and credential for one Client installation and allows the target Runtime Host to grant Session authority. Its one-time payload, identity, receipt, durable state, and revocation authority remain independent from Mesh invitation and membership state. It grants no connectivity admission or discovery.

Collaboration grants remain usable over any separately authorized transport. Removing a node from a future mesh does not revoke them, and revoking a collaboration invitation, credential, or Session grant does not remove Mesh membership.

A future QR code or link may package opaque Mesh and collaboration invitation payloads for one scan. The Mesh and Host authorities validate and commit their own payloads and report their own outcomes; the envelope provides no shared durable membership or cross-authority atomicity guarantee.

Initial Client scope

The first product vertical slice is Desktop Owner ↔ Desktop Guest. The Host protocol, durable grants, Access Requests, attribution, revocation, and authorization semantics remain Client-neutral from the start and are covered by protocol/conformance tests.

CLI and TUI do not need complete sharing surfaces in this milestone. Until a Client implements them, it must receive no fallback or implied Owner authority: the Host rejects unauthorized operations, and unsupported Guest/approval workflows remain unavailable. Their complete observation, request, and approval experiences are separate Client milestones.

Initial identity and grant model

The initial collaboration milestone reuses the existing identity primitives:

• principalId is the stable authorization subject;
• credentialId and its secret are replaceable authentication material;
• clientInstanceId identifies a Client installation for lifecycle purposes but is not a security identity and is not used by resource grants.

Each collaboration invitation creates one restricted Guest principal for one installation. The initial milestone uses a closed union of two typed Session grants:

• SessionObservationGrant: discover the Session and observe its historical and live user-visible projection;
• SessionTurnRequestGrant: standing authority to submit proposed Turns for Owner approval.

Each grant carries grantId, principalId, sessionId, createdAt, revision, and optional revokedAt. The schema has no arbitrary action strings, durable roles, allow/deny combinations, or generic policy evaluator. Grant kinds do not imply one another; user-facing access levels are presets that create the required typed grants.

Because grants bind principalId rather than credentialId, credential rotation preserves access. A second device or reinstallation requires a new collaboration invitation, a new Guest principal, and explicit grants. The initial milestone introduces no Subject table, Device table, human-identity aggregation, automatic grant inheritance, account recovery, or cross-device synchronization.

Session observation

An observation-only Guest can observe the complete shared user-visible Session projection but cannot submit or control Runtime work. Observation limits authority; it does not make the readable content inherently safe.

Turn contribution

SessionTurnRequestGrant is standing authority to request contribution; it is not the request record. Each concrete AccessRequest binds the requesting principal, Session, and one immutable exact turn.start intent. Owner Clients observe and atomically resolve it; approval admits only that intent. Approval survives Client disconnect and Host recovery, concurrent decisions produce one canonical result, and one-time approval creates no ambient future permission.

This grant does not permit starting a Turn directly, interrupting or stopping work, resolving interactions, or managing sharing. Existing Session history remains immutable; contribution appends a new execution intent rather than editing prior content.

Direct contribution (later milestone)

A standing SessionTurnStartGrant would repeatedly authorize model spending and any tool, file, credential, or external effect available to the target Session. It is not part of the initial milestone. A separate proposal must justify it with measured approval friction and define its execution-authority boundary before implementation approval.

Revocation

Grant changes take effect without reconnecting:

• inaccessible subscriptions stop;
• future operations are rejected;
• pending intents are cancelled or re-evaluated;
• committed facts retain correct attribution.

Revocation cannot make previously projected information secret again.

Staged delivery

1. Add a restricted Guest principal kind, purpose-bound collaboration invitation/finalization, and a grant store closed to SessionObservationGrant and SessionTurnRequestGrant.
2. Deliver informed Session observation with Host-side projection filtering, immediate revocation, and credential rotation.
3. Add durable immutable Access Requests for exact proposed Turns and the Desktop Owner approval flow. This completes the initial Desktop collaboration milestone.
4. Evaluate standing direct Turn authority separately using measured approval friction and an explicit execution-authority boundary; it is not pre-approved here.
5. Evaluate interrupt, interaction-resolution, and sharing-management grants independently; they are not implied by Turn contribution.

Acceptance criteria

• Sharing works independently of whether connectivity uses TLS, SSH, acknowledged plaintext, an external overlay, or Maka peer connectivity.
• Plaintext collaboration requires both Host opt-in through --allow-insecure-remote and a separately persisted Guest Client acknowledgement.
• Plaintext UX states that Guest credentials, complete shared Session content, and Turn requests are unencrypted and may be intercepted.
• Collaboration invitations never create, select, or downgrade to plaintext automatically.
• A collaboration invitation never grants Mesh admission or discovery.
• Mesh removal and collaboration credential/grant revocation remain independent across every transport.
• A combined QR/link is only an envelope for separately validated, committed, and reported one-time payloads.
• Connecting or joining a peer network never implies Owner or Session authority.
• An observation-only Guest sees the complete user-visible content of only explicitly granted Sessions and cannot submit or control Runtime work.
• Sharing confirmation accurately states that embedded paths, file content, credentials, or secrets are not automatically hidden.
• Host-private structured state and unrelated resources are filtered before projection.
• SessionTurnRequestGrant is standing permission to create requests, while each Access Request stores one immutable exact Turn intent.
• A Guest with SessionTurnRequestGrant can request one exact Turn, but no Runtime work starts before approval.
• Turn contribution does not implicitly grant direct Turn start, interrupt, interaction-resolution, or sharing-management authority.
• Credential rotation preserves grants because they bind the Guest principal rather than authentication material.
• A new installation receives no grant automatically and requires a new collaboration invitation.
• Revocation removes future access without restarting Host or Client and does not claim to retract prior disclosure.
• Approval remains pending while Owners are offline and survives Host recovery.
• Concurrent Owner decisions produce one canonical result.
• Every accepted Guest action and approval is correctly attributed.
• Every admitted Guest Turn is attributed to the initiating principal and the grant or approval that authorized it.
• Desktop Owner and Desktop Guest complete the observation, exact Turn request, durable decision, admitted Turn, and result-observation flow.
• Protocol/conformance tests establish Client-neutral grant, Access Request, attribution, revocation, and authorization semantics.
• CLI and TUI without sharing surfaces fail closed: they gain no implied Owner authority and cannot bypass Host authorization.

Non-goals

• Semantic redaction of arbitrary granted Session content
• Guaranteeing that a shared existing Session contains no paths, credentials, or secrets
• A separate owner-private/guest-visible canonical fact partition in the first milestone
• Subject and Device tables, human-identity aggregation, multi-device grant inheritance, or account recovery in the first milestone
• Peer discovery, NAT traversal, or transit routing
• Host-wide access through a normal collaboration invitation
• Sharing Host settings, credential stores, or unrestricted filesystem access
• Project-wide, team-wide, or all-future-Session grants in the first milestone
• A generic policy language
• Standing direct Turn-start authority in the initial milestone
• Complete CLI or TUI sharing and approval UX in the initial milestone
• Client-side filtering of an over-broad Host projection
• Federated Runtime Hosts or cross-Host grant replication
• A unified invitation, identity, membership, receipt, or revocation authority spanning connectivity and Runtime resources
• Atomic commit across Mesh and collaboration invitation payloads

简体中文

问题

当前经过认证的远程 Runtime Host Client 拥有接近 Owner 的访问能力。Host 无法让另一个人安全地读取或参与选定 Sessions，同时避免暴露无关 Sessions、Projects、settings、credential stores、filesystem catalogs、diagnostics 或 execution authority。

Connectivity 与资源授权彼此独立。Session sharing 必须既能通过现有 TLS/SSH 连接工作，也能通过未来的 peer connectivity 工作；加入一个网络本身不能授予访问权限。

本 issue 替代 #3801 中的 sharing 与 collaboration 范围。Application-scoped peer connectivity 由 #3842 独立跟踪。

期望结果

Runtime Host 支持独立认证的 Guest principals，同时继续作为以下事项的唯一 authority：

• 某个 principal 可以发现或观察哪些 Sessions；
• 可以提交哪些 intents；
• 哪些 actions 需要 Owner approval；
• 立即 revoke 和移除 subscription；
• 对已接受 action 和 durable decision 的 attribution。

初始 collaboration milestone 同时包含明确的 Session observation 和经 approval 准入的 Turn contribution。Observation 是第一个实现切片，而不是产品终点；只有 Guest 能观察 shared Session、提出一个精确 Turn、由 Host/Owner 在 durable authority 下准入，并观察结果，这个 milestone 才算完成。

Shared Session 内容契约

分享既有 Session，表示 Owner 明确授权 Guest 读取该 Session 完整的用户可见 canonical content，包括既有历史以及 grant 有效期间的 live content。

这包括 Session 体验中可见的内容，例如：

• 用户和 assistant 消息；
• 用户可见的 reasoning 或 thinking projection；
• tool 名称、参数、状态、stdout、stderr 和 result；
• 已进入用户可见 Session projection 的附件或引用；
• Guest 保持访问期间产生的同类未来内容。

如果这些内容已经包含绝对路径、粘贴的 token、credential、文件内容或其他秘密，Guest 也能看到。Host 无法在事后可靠分类任意文本，也无法在不改变含义的情况下删除敏感字符串。因此第一阶段不进行 share-time semantic redaction，也不承诺隐藏已经嵌入 granted Session 内容中的秘密。

从未进入用户可见 canonical Session projection 的内容继续保持私有，包括隐藏的模型推理、system prompt、provider 原始请求、内部 Runtime state，以及 Client-local draft 或 presentation state。

Host-private 结构状态

Session grant 不暴露无关或 Host-private 结构状态。Host 必须在 projection 前过滤，不能依赖 Client 隐藏。

例如：

• 用户可见 Session 内容之外的 workspace.hostCwd 和其他 Host path metadata；
• 无关 Session ID、标题或数量；
• Project catalog 和 filesystem discovery；
• Host settings、credential stores 和 provider configuration；
• 无关 interaction、usage、diagnostics 和 environment information。

外部通常不应区分资源不存在和无权访问。

知情分享

授予 Session observation 前，必须准确告知 Owner：

• Guest 会获得完整的既有用户可见 Session 历史；
• grant 有效期间的新用户可见 live content 也可以被读取；
• 已嵌入内容的路径、文件内容、credential 或秘密不会被自动隐藏；
• revoke 会停止未来访问，但无法收回 Guest 已读取或复制的内容。

Preview 可以帮助 Owner 检查 Session，例如展示时间范围、消息和 tool-call 数量以及最近内容，但不能声称已经检测出所有敏感信息。

架构边界

Connectivity 提供经过认证的 transport stream；是否加密取决于所选 transport。Connectivity 不授予任何应用权限。

目标 Runtime Host 持有 Guest principal kind、credential、resource grant、Access Request、revocation 和 projection filtering。每个 request、subscription 和 canonical rebuild 都动态计算授权。

Connectivity
  TLS / SSH / acknowledged plaintext / peer connectivity
       │ 经过认证的连接
       ▼
Runtime Host Access Authority
       │ 经过授权的 intent 和 projection
       ▼
Session / Interaction domains

Plaintext transport 契约

Acknowledged plaintext 仍是显式不安全、但经过认证的 transport。只有 Host 以 --allow-insecure-remote 启动，并且 Guest Client profile 单独持久记录用户的风险确认时，才可以承载 collaboration traffic。

Plaintext 不加密 Guest credential、完整 shared Session content 和 Turn request。同一网络中能够观察流量的第三方可能截获这些内容。Collaboration invitation 不得自动创建 plaintext profile、把现有 profile 改为 plaintext，或在 secure connection 失败后降级到 plaintext。

Transport 选择不改变 resource authority：认证后，Host 仍执行相同的 principal、grant、Access Request、attribution 和 revocation 规则。

Invitation authority 边界

Collaboration invitation 为一个 Client 安装创建受限 Guest principal 和 credential，并允许目标 Runtime Host 授予 Session authority。它的 one-time payload、identity、receipt、durable state 和 revocation authority，必须与 Mesh invitation 和 membership state 永久独立；它不授予 connectivity admission 或 discovery。

Collaboration grant 可以继续通过任何独立授权的 transport 使用。将 node 移出未来 mesh 不会撤销这些 grants；撤销 collaboration invitation、credential 或 Session grant 也不会移除 Mesh membership。

未来一个 QR code 或 link 可以封装 opaque Mesh 与 collaboration invitation payload，以提供一次扫码体验。Mesh 与 Host authorities 分别验证并提交各自 payload，并分别报告结果；该 envelope 不提供共享 durable membership，也不保证跨 authority 原子性。

初始 Client 范围

首个产品 vertical slice 是 Desktop Owner ↔ Desktop Guest。Host protocol、durable grants、Access Requests、attribution、revocation 和 authorization semantics 从第一天起保持 Client-neutral，并由 protocol/conformance tests 锁定。

CLI 和 TUI 无需在这个 milestone 内提供完整 sharing surface。在对应能力实现前，它们不能获得 fallback 或隐含 Owner authority：Host 拒绝未授权 operation，不支持的 Guest/approval workflow 保持不可用。完整的 observation、request 和 approval 体验分别作为后续 Client milestones。

初始身份与 grant 模型

初始 collaboration milestone 复用现有 identity primitives：

• principalId 是稳定的授权主体；
• credentialId 及其 secret 是可替换的认证材料；
• clientInstanceId 只用于标识 Client 安装实例及其生命周期，不是安全身份，也不参与 resource grant。

每次 collaboration invitation 为一个安装创建一个受限 Guest principal。初始 milestone 使用仅包含两种 typed Session grants 的封闭 union：

• SessionObservationGrant：发现 Session，并观察其历史和 live user-visible projection；
• SessionTurnRequestGrant：持续授予提交 Turn proposal 供 Owner 批准的 authority。

每个 grant 都包含 grantId、principalId、sessionId、createdAt、revision 和可选的 revokedAt。Schema 不包含任意 action 字符串、durable role、allow/deny 组合或通用 policy evaluator。Grant kinds 彼此不隐含；用户可见的 access level 只是创建所需 typed grants 的 presets。

由于 grants 绑定 principalId 而非 credentialId，credential rotation 不改变访问权。第二台设备或重新安装需要新的 collaboration invitation、新的 Guest principal 和明确 grants。初始 milestone 不增加 Subject 表、Device 表、人类身份聚合、grant 自动继承、账号恢复或跨设备同步。

Session observation

只有 observation 权限的 Guest 可以观察完整的 shared user-visible Session projection，但不能提交或控制 Runtime 工作。Observation 限制的是 authority，不会让可读内容天然安全。

Turn contribution

SessionTurnRequestGrant 是持续的 contribution request authority，不是请求记录。每个具体 AccessRequest 绑定 requesting principal、Session 和一个不可变的精确 turn.start intent。Owner Clients 观察并原子 resolve；approval 只准入该 intent。Approval 在 Client 断线和 Host recovery 后继续存在，并发 decision 只产生一个 canonical result，单次批准不会形成隐式的未来权限。

该 grant 不允许直接启动 Turn、interrupt 或 stop、resolve interaction 或管理 sharing。既有 Session 历史保持不可修改；参与表示追加新的 execution intent，而不是编辑既有内容。

直接参与（后续 milestone）

持续的 SessionTurnStartGrant 会反复授权模型开销，以及目标 Session 可用的工具、文件、credential 或 external effect。它不属于初始 milestone。实施前必须通过独立提案，以实测 approval friction 证明必要性，并定义清楚 execution-authority boundary。

撤销

Grant 变化无需重连即可生效：

• 停止无权访问的 subscriptions；
• 拒绝后续 operations；
• 取消或重新判断 pending intents；
• 已提交事实保留正确 attribution。

Revoke 无法让已经 projection 的信息重新成为秘密。

分阶段交付

1. 增加受限 Guest principal kind、purpose-bound collaboration invitation/finalization，以及仅包含 SessionObservationGrant 和 SessionTurnRequestGrant 的封闭 grant store。
2. 交付知情的 Session observation、Host-side projection filtering、立即 revoke 和 credential rotation。
3. 为精确 Turn proposal 增加 durable immutable Access Request 和 Desktop Owner approval flow；至此完成初始 Desktop collaboration milestone。
4. 根据实测 approval friction 和明确的 execution-authority boundary 独立评估持续 direct Turn authority；本 issue 不预先批准。
5. 分别评估 interrupt、interaction-resolution 和 sharing-management grants；Turn contribution 不隐含这些权限。

验收标准

• Sharing 不依赖 connectivity 使用 TLS、SSH、acknowledged plaintext、external overlay 还是 Maka peer connectivity。
• Plaintext collaboration 同时要求 Host 通过 --allow-insecure-remote opt in，并由 Guest Client 单独持久记录风险确认。
• Plaintext UX 明确说明 Guest credential、完整 shared Session content 和 Turn request 未加密且可能被截获。
• Collaboration invitation 永远不会自动创建、选择或降级到 plaintext。
• Collaboration invitation 永远不授予 Mesh admission 或 discovery。
• Mesh removal 与 collaboration credential/grant revocation 在所有 transport 上保持独立。
• Combined QR/link 只是分别验证、提交和报告的 one-time payload envelope。
• 建立连接或加入 peer network 永远不隐式获得 Owner 或 Session authority。
• 只有 observation 权限的 Guest 只能看到明确授权 Sessions 的完整用户可见内容，并且不能提交或控制 Runtime 工作。
• Sharing confirmation 准确说明嵌入的路径、文件内容、credential 或秘密不会被自动隐藏。
• Host-private 结构状态和无关资源在 projection 前被过滤。
• SessionTurnRequestGrant 是持续的 request permission；每个 Access Request 保存一个不可变的精确 Turn intent。
• 持有 SessionTurnRequestGrant 的 Guest 可以请求一个精确 Turn，但批准前不会启动 Runtime 工作。
• Turn contribution 不隐式授予 direct Turn start、interrupt、interaction-resolution 或 sharing-management authority。
• Credential rotation 保留 grant，因为 grant 绑定 Guest principal 而非认证材料。
• 新安装不会自动获得 grant，必须接受新的 collaboration invitation。
• Revoke 无需重启 Host 或 Client 即可移除未来访问，并且不声称收回此前披露。
• Owner 离线时 approval 保持 pending，并在 Host recovery 后恢复。
• 多个 Owner 的并发 decision 产生一个 canonical result。
• 每个接受的 Guest action 和 approval 都具有正确 attribution。
• 每个 admitted Guest Turn 都能归因到发起 principal，以及授权它的 grant 或 approval。
• Desktop Owner 与 Desktop Guest 完成 observation、精确 Turn request、durable decision、admitted Turn 和结果 observation 的闭环。
• Protocol/conformance tests 锁定 Client-neutral 的 grant、Access Request、attribution、revocation 和 authorization semantics。
• 尚无 sharing surface 的 CLI/TUI fail closed：不会获得隐含 Owner authority，也不能绕过 Host authorization。

非目标

• 对任意 granted Session 内容进行 semantic redaction
• 保证 shared existing Session 不包含 path、credential 或 secret
• 第一阶段增加 owner-private/guest-visible canonical fact 分区
• 第一阶段增加 Subject/Device 表、人类身份聚合、多设备 grant 继承或账号恢复
• Peer discovery、NAT traversal 或 transit routing
• 通过普通 collaboration invitation 获得 Host-wide access
• 分享 Host settings、credential stores 或不受限制的文件系统访问
• 第一阶段支持 Project、team 或所有未来 Session 范围的 grant
• 通用 policy language
• 初始 milestone 中的持续 direct Turn-start authority
• 初始 milestone 中完整的 CLI 或 TUI sharing/approval UX
• 由 Client 过滤过宽的 Host projection
• Federated Runtime Host 或跨 Host grant replication
• 横跨 connectivity 与 Runtime resource 的统一 invitation、identity、membership、receipt 或 revocation authority
• Mesh 与 collaboration invitation payload 的跨 authority 原子提交