Claude Code 会话链接与 Git 署名：检查、关闭与历史处理

先看结论：会话链接、Claude 归因文案和 Git 作者身份不是同一层记录，不能用一个开关或一个风险判断处理。

在 GitHub 提交页看到 Claude-Session: https://claude.ai/code/session_...，并不表 示 Claude 变成了这个提交的 Git 作者，也不能单凭这条 URL 判断会话内容已经公开。它首先是一条写在提交信息里的会话链接。真正需要处理的问题有三个：链接是否应该继续写入、Claude 的归因文案是否符合团队政策、以及旧提交是否造成了实际暴露。

这三个问题不能用同一个旧开关解决。Claude Code 当前把它们拆成了独立设置：attribution.sessionUrl 控制会话链接，attribution.commit 控制提交信息中的归因文字，attribution.pr 控制 PR 描述中的归因文字。根据 2026 年 8 月 31 日核验的 Claude Code Git 与归因设置，cloud 或 Remote Control 会话创建提交或 PR 时，sessionUrl 默认是 true。

先分清记录里的三层信息

下面是一段可能出现的提交信息：

text
Fix token refresh race

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_...

Co-Authored-By 和 Claude-Session 都属于提交信息的 trailer（尾注）。Git 还在提交对象中单独保存 author 与 committer：author 通常表示原始修改作者，committer 表示最终创建这个提交对象的人。托管平台可以突出显示共同作者尾注，但它不会因此覆盖 Git 的 author/committer 字段。

检查一个提交时，把两层信息同时打印出来：

bash
git show -s \
  --format='author: %an <%ae>%ncommitter: %cn <%ce>%n%n%B' \
  <commit>

前两行是 Git 身份，后面是完整提交信息。修改 Claude Code 的归因设置不会更改已有提交的 author、committer、签名或本机的 user.name、user.email。

还有一种容易混淆的 URL：claude-cli:// deep link 用来在本机打开一个预填目录或提示词的新会话；它不是 Claude-Session 记录的 https://claude.ai/code/session_... 会话页面。二者用途不同，Anthropic 在 Claude Code 链接启动说明 中单独说明了前者。

不打开链接，也能完成仓库检查

先用只读 Git 命令找出所有本地引用中的会话尾注：

bash
git log --all --grep='^Claude-Session:' \
  --format='%h %ad %s%n%(trailers:key=Claude-Session,only)%n' \
  --date=short

再单独检查共同作者尾注：

bash
git log --all \
  --format='%h %ad %s%n%(trailers:key=Co-Authored-By,only)%n' \
  --date=short

这两个命令不会访问 Claude 会话。Git 官方的 git log 文档 对边界定义得很清楚：--grep 匹配提交信息，--author 与 --committer 匹配提交对象中的身份字段，%(trailers:...) 用于解析提交信息尾注。

第一条命令没有输出，说明当前本地仓库可达的 refs 中没有匹配项；它不能证明远程已删除分支、其他人的 clone、fork 或托管平台缓存从未保存过旧对象。普通预防场景不必无限扩大调查范围；只有确认发生了敏感信息事件，才需要盘点远端与协作者副本。

会话链接本身也不是访问权限。Anthropic 的 Web 会话共享说明 显示，Team/Enterprise 与 Pro/Max 账户使用不同的可见性选项，并可能结合组织成员、GitHub 仓库访问检查或登录状态。公共仓库里的 URL 文本当然人人可见，但目标会话能否被打开，需要按当前会话可见性和接收者身份实测，不能靠 URL 外观推断。

只关闭会话链接

如果团队希望保留“由 Claude 协作”的归因信息，只是不希望提交和 PR 携带会话入口，配置应当保持最小：

json
{
  "attribution": {
    "sessionUrl": false
  }
}

这个布尔值不会自动清空 Co-Authored-By 或 PR 中的 Claude 说明。如果目标是三项都不写，应把选择完整表达出来：

json
{
  "attribution": {
    "commit": "",
    "pr": "",
    "sessionUrl": false
  }
}

commit 和 pr 也可以换成团队自己的透明披露文案，而不是设为空字符串。提交文案可以包含 Git trailer，PR 文案则写入 PR 描述。没有设置的字段继续使用 Claude Code 当时的默认内容。

旧配置中的 includeCoAuthoredBy 已在 v2.0.62 起弃用。Claude Code 为兼容旧文件仍可能读取它，但新配置应使用 attribution。尤其是会话 URL 已经有独立开关，单写 includeCoAuthoredBy: false 不能清楚表达“保留其他归因、只去掉链接”的意图。

设置放在哪个文件，决定谁会继承

同一段 JSON 放在不同位置，治理含义完全不同：

Claude Code 设置与作用域文档 给出的普通优先级依次是 managed、命令行、local、project、user。所以下层文件即使 JSON 正确，也可能被更高层覆盖。

修改后启动一个新的相关会话，运行：

text
/status

Status 会列出实际加载的设置来源，并报告无效 JSON 或不接受的值；它不会逐项告诉你某个 key 最终来自哪一层。若多层都定义了 attribution，应按优先级逐层检查。对于 cloud 会话，提交到仓库的 .claude/settings.json 才会随全新 clone 到达环境；笔记本上的 .claude/settings.local.json 不会凭空同步过去。

验证时不要直接制造业务提交。可以在临时分支或测试仓库里，让实际使用的同一类 Claude Code 会话创建一个无害提交，再用下面的命令读取结果：

bash
git show -s --format=fuller

如果要验证 cloud 或 Remote Control 的会话链接行为，就必须从对应利用面生成测试提交。本地终端测试通过，只能证明本地路径，不能替代 cloud 路径验证。

旧提交是否要改，先看风险等级

尚未共享的最后一个提交，可以用 git commit --amend 修改信息；更早的本地提交可以在确认分支边界后用交互式 rebase 选择 reword。这类操作仍会产生新的提交 ID，但影响只在本地，容易控制。

如果提交已推送，而会话无法被无关人员访问、内容也没有敏感数据，通常更稳妥的做法是关闭未来写入并记录团队政策，而不是为了外观一致强行改写历史。改写会影响提交 ID、签名、开放中的 PR、发布引用与协作者分支。

如果合规政策确实要求从已发布历史移除链接，先协调所有协作者，再决定变基和更新远端引用。GitHub 的 修改提交信息说明 明确提醒：改写提交信息会创建新 ID，force push 可能干扰协作；即使更新分支，旧敏感提交也可能仍能通过旧对象 ID 找到。

如果打开链接后确认会话暴露了 API key、私钥、客户数据或其他秘密，这就不再是署名偏好。第一步是限制会话可见性，并吊销或轮换秘密；随后保留响应所需证据，协调历史清理与托管平台支持。GitHub 的 敏感数据清理指南 也指出，仅改写 Git 历史不能使已暴露的凭据失效，旧 clone 还可能把数据重新带回远端。

最稳妥的顺序是：确认记录属于哪一层，选择最小的独立开关，在真实会话类型中验证，再按实际可见性与敏感度决定旧历史。这样既不会把追溯链接误认成 Git 作者，也不会为一个未形成风险的尾注破坏整个协作历史。