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

> 分清 Claude-Session 会话链接、Co-Authored-By 提交尾注和 Git 作者身份，检查仓库记录，选择正确设置作用域，并安全处理已有提交。

- Source: https://www.aifreeapi.com/zh/posts/claude-code-session-url-git-attribution
- Language: zh
- Published: 2026-08-31
- Updated: 2026-09-12
- Publisher: AI Free API (https://www.aifreeapi.com)

会话链接、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 与归因设置](https://code.claude.com/docs/en/settings-reference#git-and-attribution)，云端或 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' \
  HEAD
```

示例查看最新提交；将 `HEAD` 换成目标提交 ID 即可检查其他提交。前两行是 Git 身份，后面是完整提交信息。修改 Claude Code 的归因设置不会更改已有提交的 author、committer、签名或本机的 `user.name`、`user.email`。

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

![中文审计与设置速览图，展示提交信息尾注、Git author/committer、只读检查命令、独立 attribution 配置、设置优先级和历史风险等级](https://www.aifreeapi.com/posts/zh/claude-code-session-url-git-attribution/img/audit-settings-map.webp)

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

先用只读 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` 文档](https://git-scm.com/docs/git-log) 对边界定义得很清楚：`--grep` 匹配提交信息，`--author` 与 `--committer` 匹配提交对象中的身份字段，`%(trailers:...)` 用于解析提交信息尾注。

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

会话链接本身也不是访问权限。Anthropic 的 [Web 会话共享说明](https://code.claude.com/docs/en/claude-code-on-the-web#work-with-sessions) 显示，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/settings.json` | 当前用户的默认行为 |
| 仓库统一执行团队政策 | `.claude/settings.json` | 提交后由协作者和云端克隆环境 读取 |
| 只在当前克隆副本试验或覆盖 | `.claude/settings.local.json` | 当前用户、当前项目，通常被 Git 忽略 |
| 组织强制要求 | Managed settings | 由管理员下发，优先级最高 |

[Claude Code 设置与作用域文档](https://code.claude.com/docs/en/settings) 给出的普通优先级依次是 managed、命令行、local、project、user。所以下层文件即使 JSON 正确，也可能被更高层覆盖。

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

```text
/status
```

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

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

```bash
git show -s --format=fuller
```

如果要验证云端或 Remote Control 会话是否附带链接，就要在对应类型的会话中生成测试提交。本地终端里的结果不能代替云端验证。

![中文决策图，按三层元数据、只读审计、最小独立设置、配置作用域和敏感信息风险划分旧提交的处理方式](https://www.aifreeapi.com/posts/zh/claude-code-session-url-git-attribution/img/history-risk-decision.webp)

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

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

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

如果合规政策确实要求从已发布历史移除链接，先协调所有协作者，再决定变基和更新远端引用。GitHub 的 [修改提交信息说明](https://docs.github.com/en/pull-requests/how-tos/commit-changes/changing-a-commit-message) 明确提醒：改写提交信息会创建新 ID，force push 可能干扰协作；即使更新分支，旧敏感提交也可能仍能通过旧对象 ID 找到。

如果打开链接后确认会话暴露了 API key、私钥、客户数据或其他秘密，这就不再是署名偏好。第一步是限制会话可见性，并吊销或轮换秘密；随后保留响应所需证据，协调历史清理与托管平台支持。GitHub 的 [敏感数据清理指南](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository) 也指出，仅改写 Git 历史不能使已暴露的凭据失效，旧克隆副本还可能把数据重新带回远端。

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