实时共享 AI 编程会话：只读链接协议与状态同步设计
共享实时编程会话意味着发送一个包含三项内容的链接：打开哪个画布、对方拥有编辑权限还是仅能观看，以及其光标上显示的名称。运行中的应用必须通过同一认证会话进行代理转发。
屏幕共享展示的是某个人的屏幕画面。对于可能持续运行二十分钟的代理而言，这种模式并不适用，因为关键在于机器正在做什么，而发起者可能已经去休息了。我们想要的是一个简单的链接：发送出去，对方点击打开，便直接置身于同一个房间中。
三项数据，且没有一项是视频流
系统没有传输任何视频流。会话原本就没有运行在任何人的笔记本上，因此加入并不是在两台电脑之间复制像素。链接只需传递三个基本事实：打开哪块画布、进入者被允许做什么，以及在房间里如何称呼他们。
第二点往往被人们低估。只读画布与可编辑画布展现相同的画面，但属于两种完全不同的产品形态，这种差异必须固化在 Token 权限中，而不能仅停留在前端界面上。对观察者隐藏输入框只是一种界面建议；而未授予写权限的链接则是不可逾越的安全规则。
第三点将共享屏幕转变为协作空间。画布上的每个人都显示为一个彩色圆点和名字，旁边的状态标明他们是在观看还是在编辑。画布上的鲜艳色彩只代表代理或人类，绝不用于装饰。
极易产生严重安全隐患的预览环节
代理负责构建应用程序，观看它们的核心目的在于观察应用的运行效果。因此画布提供了实时预览：一个展示沙箱内开发服务器渲染内容的窗口，并随代码修改自动刷新。
最具有诱惑力但也最危险的做法是为每个沙箱分配独立的公网二级域名。我们坚决拒绝了这种方案：任何公开可访问的 URL 都是可被绕过的后门，这意味着共享功能会悄然将某人未完成的开发应用以可猜测的域名发布到公网上。
因此，预览完全通过已认证的会话通道进行转发。浏览器向控制平面发起请求，携带分钟级有效期的短期授权凭据。控制平面通过终端复用的同一链路转发请求，并在沙箱内部请求 localhost。根本不存在任何公网预览主机名。
为此付出的权衡代价
通过 WebSocket 会话反向代理开发服务器比单纯配置 DNS 复杂得多，并对单次响应大小施加了上限约束。
我们认为这种取舍是完全正确的。预览的初衷是让构建应用的团队成员实时验证成果，其可访问范围应严格等同于画布本身的权限，杜绝任何意外的公开泄露。
共享机制真正改变了什么
当会话变成一个链接而非一台本地机器时，协作不再需要预约时间或发起会议，即使创建者关闭标签页，代理也会持续运转。保持浏览器与远程终端的可靠连接探讨了底层的连接保障。
关于实时多人协作的机制请参阅 与 AI 代理的多人协作编码，终端流控请参阅 观察不属于你的终端。
直接回答
如何与团队共享 Claude Code 会话？
在 Murmell 上只需发送画布链接。打开链接的人即可加入同一画布，实时观看终端输出，并显示为带名字的光标。无需安装软件或发起屏幕共享。
是否允许他人仅观看而不具备输入权限？
允许。链接内置角色定义，画布可以以只读模式分发，界面清晰标注各参与者是正在观看还是正在编辑。
代理正在构建的网页应用会被拥有 URL 的任何人随意访问吗？
不会。开发服务器监听在沙箱内部的 localhost，通过已认证的画布会话使用短期授权进行安全反向代理，不存在可被猜测的公网预览域名。