企业官网建设流程全解析

🔐 如果你正在使用claude-share（Claude Code 的多人协作插件），那么权限审批机制一定是你最该关注的部分。claude-share 让你把 Claude Code 会话分享给队友，但队友的提示词是在Host（主人）的机器上真实执行的——一次越权的写入或命令，可能直接改坏你的代码。这篇文章用大白话拆解 claude-share 的权限审批机制：Host 如何通过"默认询问、符号链接检查、Agent 归属、人员信任、安全兜底"这5 道关卡，守住代码安全。

为什么 claude-share 必须有权限审批

先理解 claude-share 的协作模型，安全边界才说得通：

• 一台机器干活：共享的那个会话是 Host，队友（Guest）的提示词会传到 Host 的机器上，作为 Host 会话的一个回合来运行；
• Guest 的模型从不被调用：Guest 看到的工具调用只是 Host 结果的"回放"，不会在 Guest 电脑上执行任何东西；
• 审批权永远在 Host：默认情况下，Guest 提示词引发的每次文件编辑、命令执行、网络访问，都会先问 Host。

💡 一句话总结：Guest 只"说话"，Host 才"动手"，而且每次动手都要过关卡。

关卡一：默认询问——"Host is asked, never answered for"

claude-share 的核心设计规则只有一句话：Host 会被询问，但从来不会被人"代答"（源码见 docs/rules/host.md）。

具体表现：

• 队友发起的每个敏感调用（写文件、跑命令、访问网络）都会以审批的形式弹给 Host，无论 Host 自己处于什么权限模式——即使 Host 开了宽松模式，队友的操作也要单独过问；
• 每个审批都会显示确切的命令或 diff，Host 看到的就是真实要执行的内容；
• 等待中的调用排在同一个队列里，最老的先回答，每个调用只能被它自己的对话框或按钮回答，且每次都要重新审视信任状态。

Host 的回答只有三个选项：Allow once（允许一次）、Always allow（始终允许）、Decline（拒绝）。这些选项的实现位于 plugin/hooks/register.tsx。

关卡二：只放行"真在项目里"的读操作

写操作默认要问，那读操作呢？claude-share 的策略是：只有确实待在项目目录内的读取才免询问（源码中的readsInsideReally）。

这一关防的是最典型的越权手段——符号链接：

• 先解析读工具"点名"的路径：Glob 模式取到第一个通配符为止，其余路径原样保留（实现见 plugin/hooks/paths.ts）；
• 再逐个核实路径真实指向哪里，并跟随符号链接（用 plugin/relay/real.sh 解析真实路径）；
• 如果项目里的一条链接指向了项目外（比如指向宿主机其他目录），这次读取必须询问 Host；
• 如果一条路径"说不清真实位置"（悬空链接），或解析超过 5 秒，同样会转成询问。

换句话说：哪怕路径写在项目里，只要它"真的"指向外面，关卡二就会拦下。

关卡三：Agent 的调用跟着"发起人"走

Agent（子代理）是最容易甩锅的对象——"这个调用不是我直接发的，是 Agent 干的"。claude-share 不认这种说法：

• 一个 Agent 的调用算作启动它的那个回合的人（callOwner），agent.spawn会记录每个 Agent 的归属；
• 队友启动的 Agent，即使在 Guest 的回合结束后很久仍在运行，它的调用依然算 Guest 的，每次都要问 Host；
• 在 Guest 回合运行期间，Host 自己 Agent 的调用也会被视作该 Guest 的调用来询问。

也就是说：谁让 Agent 跑起来的，Agent 干的每件事就归谁审批，没有"借 Agent 之手"的灰色地带。规则出处：docs/rules/host.md。

关卡四：Always allow 信任的是"人"，不是"名字"

点了Always allow，是不是以后叫这个名字的都能放行？不是。这是 claude-share 权限审批里最精细的一关：

• 信任记录（trusts/ShareTrust）绑定的是这个人 + 提示词所在的席位（seat），席位信息从房间事件一路带到回合、调用和 Agent；
• 信任可以匹配到对方的账号（seatAccount）：同一个人用同一账号开的新会话也会被信任；
• 但一个冒用"Alex"名字的新人加入，照样会被逐次询问——名字是自我声明的，不可信，账号才是。

一句话：信任跟着账号和席位走，名字只是一个标签。实现细节可参见 docs/rules/host.md 与 plugin/hooks/register.tsx。

关卡五：所有"没答上来的问题"都默认判 No

安全系统最容易被忽视的，是异常路径。claude-share 把所有回答不上的情况，一律倒向拒绝：

这个设计对应 docs/rules/host.md 中"Host 被询问，但从不被代答"的原则：宁可拦住，不可漏放。

额外防线：Host 的控制面

除了 5 道关卡，Host 还握着两个总开关：

• 只读模式：分享时选择Only watch and chat（或/share-session watch），之后 Host 也可以随时在Room → Settings → Teammates can改成只读——队友只能看和聊天，提示词根本到不了 Claude；
• 本地端口分享逐次询问：队友的提示词可能让 Claude 点名你机器上任意端口（比如数据库、调试器）。claude-share 对每个本地 web 服务的共享都会单独问一次 Host，"Share localhost:3000 with the room?"——不点Share就不共享。

总结：5 道关卡一张表

🎯结论：claude-share 的权限审批不是"弹窗问你一下"这么简单，而是一套覆盖了执行、读取、Agent、身份、异常五个维度的纵深防御。只要记住一条——Host 被询问，但从不被代答——你就能理解它为什么敢让队友在"你的机器"上说话。

📚 延伸阅读：docs/rules/guest.md（Guest 侧规则）、docs/guide.md 中的 Security model 章节（完整安全模型）。