Ссылка на сеанс Claude Code и атрибуция Git: что именно отключать

Строка Claude-Session: https://claude.ai/code/session_... в коммите выглядит как часть личности автора, но технически это ссылка внутри сообщения коммита. Рядом может находиться Co-Authored-By, а сам объект Git отдельно хранит поля author и committer. Эти записи отвечают на разные вопросы и управляются разными средствами.

В актуальной конфигурации Claude Code три независимых параметра: attribution.commit задаёт текст в сообщениях коммитов, attribution.pr — текст в описаниях pull request, а attribution.sessionUrl — ссылку на сеанс. На 31 августа 2026 года ссылка по умолчанию включена для коммитов и PR, созданных из cloud- или Remote Control-сеанса. Это поведение и текущие значения описаны в официальном разделе Git and attribution.

Четыре вопроса вместо одного «кто автор»

Для точного решения проверьте четыре факта:

Посмотрите все поля одного коммита одной командой:

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

Первые две строки относятся к объекту Git, остальная часть — к сообщению. Удаление атрибуции Claude Code не меняет старые поля author/committer, настройки user.name и user.email или криптографическую подпись.

Не путайте эту HTTPS-ссылку с claude-cli://. Вторая является deep link: она открывает новый локальный сеанс Claude Code и предварительно заполняет каталог или запрос. Официальная документация по запуску сеансов из ссылок описывает отдельный механизм; это не ссылка на стенограмму Claude-Session.

Найдите все записи, не открывая стенограммы

Проверку можно провести локально и только для чтения. Сначала найдите ссылки на сеансы во всех доступных refs:

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

В git log эти поверхности разделены: --grep ищет в сообщении, --author и --committer фильтруют поля личности, а %(trailers:...) форматирует трейлеры. Поэтому поиск Co-Authored-By нельзя выдавать за аудит реального поля author.

Пустой результат означает, что совпадений нет в refs, достижимых в текущем клоне. Он не проверяет удалённые ветки, чужие клоны, форки и старые объекты на хостинге. Расширять расследование стоит при подтверждённом инциденте, а не для обычной настройки будущих коммитов.

Наличие URL также не доказывает публичность беседы. В правилах совместного доступа к cloud-сеансам Anthropic различает видимость для Team/Enterprise и Pro/Max, вход получателя и проверку доступа к репозиторию. В публичном коммите виден сам текст URL; доступность цели надо проверять отдельно под ожидаемой учётной записью.

Отключите только ссылку или всю атрибуцию

Если прозрачная отметка об участии Claude нужна, но ссылка на разговор не должна попадать в Git, достаточно одного значения:

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

Это не удаляет Co-Authored-By и не скрывает текст в PR. Для полного отключения всех трёх поверхностей решение должно быть явным:

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

Вместо пустых строк можно задать собственное раскрытие использования ИИ. commit принимает текст сообщения, включая трейлеры; pr управляет обычным текстом описания PR. Незаданный параметр использует текущий стандарт Claude Code.

Старый ключ includeCoAuthoredBy помечен устаревшим начиная с v2.0.62. Он всё ещё читается для совместимости, но новый объект attribution точнее разделяет коммит, PR и ссылку. Для новой конфигурации не стоит выражать независимый выбор sessionUrl через старый общий флаг.

Выберите правильный уровень конфигурации

Расположение JSON определяет область действия:

• ~/.claude/settings.json — личное правило для всех проектов;
• .claude/settings.json — общее правило репозитория, которое можно закоммитить;
• .claude/settings.local.json — личное переопределение только в этом клоне, обычно игнорируемое Git;
• managed settings — политика организации, которую нижние уровни не отменяют.

Текущий справочник по областям настроек задаёт приоритет: managed, аргументы командной строки, local, project, user. Из-за этого правильный JSON в пользовательском файле может не действовать, если проект или администратор задаёт другое значение выше.

После изменения начните новый релевантный сеанс и выполните:

text
/status

Status показывает загруженные источники и ошибки конфигурации, но не происхождение каждого отдельного ключа. Если attribution встречается в нескольких файлах, проверяйте их сверху вниз по приоритету. Для нового cloud-сеанса общее .claude/settings.json должно быть закоммичено в репозиторий: локальный файл с ноутбука не входит в свежий cloud clone.

Проверяйте поведение в тестовой ветке или отдельном репозитории. Попросите тот же тип сеанса создать безвредный коммит, затем выполните git show -s --format=fuller. Локальный терминальный тест не подтверждает поведение cloud или Remote Control, если именно они добавляли ссылку.

Когда менять старую историю

Непереданный последний коммит можно исправить через git commit --amend. Для более ранних локальных коммитов подходит интерактивный rebase с reword. Даже локально это создаёт новые идентификаторы, но границы воздействия понятны.

Для уже опубликованного неопасного URL часто разумнее оставить историю неизменной и отключить будущую запись. Косметическая чистка ломает ID, подписи, ссылки на релизы, открытые PR и ветки коллег. Сам URL может быть виден, но это ещё не означает доступ к закрытой стенограмме.

Если политика действительно требует удаления, согласуйте окно изменений и действия всех участников. Руководство GitHub Changing a commit message предупреждает, что новый текст создаёт новый commit ID, а force push способен нарушить работу коллег; старый чувствительный объект иногда остаётся доступным по прежнему ID.

Если проверка подтвердила, что стенограмма раскрыла токен, ключ, персональные данные или другой секрет, сначала ограничьте доступ и отзовите либо замените секрет. Только затем координируйте очистку Git и поддержку хостинга. В руководстве GitHub по удалению чувствительных данных отдельно объясняется, почему переписывание истории не обезвреживает секрет и как старый клон может вернуть его в репозиторий.

Безопасная последовательность такова: определить слой метаданных, изменить минимальный независимый параметр, проверить его в том же типе сеанса и лишь затем оценивать старую историю. Так трассируемость, авторство и реальный инцидент не превращаются в одну неразличимую проблему.