커밋 끝에 Claude-Session: https://claude.ai/code/session_...가 보이면 먼저 세 가지를 분리해야 합니다. 이 URL은 커밋 메시지에 들어간 세션 링크이고, Co-Authored-By는 별도의 메시지 트레일러이며, Git의 author와 committer는 커밋 객체에 저장되는 신원 필드입니다. 한 항목을 바꾼다고 나머지가 함께 바뀌지 않습니다.
Claude Code의 현재 설정도 이 경계를 그대로 반영합니다. attribution.commit은 커밋 메시지의 기여 문구, attribution.pr은 PR 설명의 문구, attribution.sessionUrl은 세션 링크를 각각 제어합니다. 2026년 8월 31일 기준 공식 Git 및 attribution 설정에 따르면 cloud 또는 Remote Control 세션에서 커밋하거나 PR을 열 때 sessionUrl의 기본값은 true입니다.
링크가 작성자 신원인지부터 확인하기
다음과 같은 커밋 메시지를 생각해 보겠습니다.
textFix token refresh race Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_...
아래 두 줄은 모두 커밋 메시지의 트레일러입니다. Git 객체의 author/committer는 이와 별도로 존재합니다. GitHub 같은 호스팅 서비스가 Co-Authored-By를 공동 작성자로 표시하더라도 원래 author 필드를 덮어쓴 것은 아닙니다.
한 커밋의 두 계층을 함께 보려면 다음을 실행합니다.
bashgit show -s \ --format='author: %an <%ae>%ncommitter: %cn <%ce>%n%n%B' \ <commit>
첫 두 줄은 Git 신원이고 그 아래는 전체 메시지입니다. Claude Code의 attribution 설정은 이미 존재하는 author/committer, 서명, user.name, user.email을 수정하지 않습니다.
claude-cli://로 시작하는 deep link도 혼동하기 쉽습니다. 이 링크는 로컬 Claude Code를 열어 디렉터리나 프롬프트를 미리 채우는 용도입니다. Claude-Session이 가리키는 HTTPS 대화 링크와는 다른 기능이며, 공식 링크로 세션 시작하기 문서에서 별도로 설명됩니다.

대화를 열지 않고 저장소 전체 점검하기
현재 로컬 저장소에서 도달 가능한 모든 refs의 세션 트레일러를 읽기 전용으로 찾을 수 있습니다.
bashgit log --all --grep='^Claude-Session:' \ --format='%h %ad %s%n%(trailers:key=Claude-Session,only)%n' \ --date=short
공동 작성자 트레일러는 별도로 확인합니다.
bashgit log --all \ --format='%h %ad %s%n%(trailers:key=Co-Authored-By,only)%n' \ --date=short
Git 공식 git log 문서는 --grep이 메시지를, --author와 --committer가 신원 헤더를, %(trailers:...)가 트레일러를 다룬다고 구분합니다. 따라서 Co-Authored-By 검색은 author 필드 점검을 대신하지 않습니다.
첫 명령에 결과가 없으면 현재 clone의 도달 가능한 refs에는 일치하는 기록이 없습니다. 삭제된 원격 브랜치, 다른 clone, fork, 호스팅 서비스의 오래된 객체까지 없다는 뜻은 아닙니다. 일반적인 예방 설정이라면 이 범위로 충분하고, 실제 민감정보 사고가 확인된 경우에만 원격과 협업자 사본까지 조사합니다.
URL이 보인다는 사실도 대화 열람 권한을 증명하지 않습니다. Anthropic의 cloud 세션 공유 설명은 Team/Enterprise와 Pro/Max의 가시성 옵션, 수신자 로그인, 조직 또는 저장소 접근 확인을 구분합니다. 공개 커밋에서는 URL 문자열이 공개되지만, 링크 대상이 열리는지는 해당 계정과 현재 공유 정책으로 별도 확인해야 합니다.
링크만 끄거나 세 항목을 모두 결정하기
Claude가 참여했다는 표시를 유지하면서 대화 링크만 빼려면 설정은 작게 유지할 수 있습니다.
json{ "attribution": { "sessionUrl": false } }
이 값은 Co-Authored-By나 PR의 Claude 문구를 없애지 않습니다. 세 항목을 모두 표시하지 않는 정책이라면 각각을 명시합니다.
json{ "attribution": { "commit": "", "pr": "", "sessionUrl": false } }
commit과 pr에는 빈 문자열 대신 팀의 자체 AI 사용 고지 문구를 넣을 수도 있습니다. commit은 Git 트레일러를 포함할 수 있는 커밋 메시지 텍스트이고, pr은 PR 설명에 들어가는 일반 텍스트입니다. 설정하지 않은 항목은 당시 Claude Code의 기본 문구를 사용합니다.
이전 includeCoAuthoredBy 키는 v2.0.62부터 deprecated입니다. 호환성을 위해 읽히기는 하지만 새 구성에서는 attribution을 사용해야 합니다. 특히 세션 링크는 독립 제어 대상이므로 오래된 단일 Boolean으로 의도를 표현하면 정책이 불명확해집니다.
설정 파일 위치가 적용 대상을 결정한다
| 목적 | 파일 | 적용 범위 |
|---|---|---|
| 개인의 모든 프로젝트에서 링크 끄기 | ~/.claude/settings.json | 사용자 기본값 |
| 저장소의 공통 정책으로 사용 | .claude/settings.json | 커밋되어 팀과 cloud clone에 공유 |
| 이 clone에서만 시험 또는 덮어쓰기 | .claude/settings.local.json | 보통 Git에서 제외되는 로컬 값 |
| 조직에서 강제 | Managed settings | 관리자가 배포하며 가장 높은 우선순위 |
Claude Code 설정 범위 문서가 설명하는 일반 우선순위는 managed, 명령줄, local, project, user입니다. 사용자 파일이 올바르더라도 더 높은 계층의 값이 있으면 행동이 달라질 수 있습니다.
수정 후에는 관련 세션을 새로 시작하고 다음 명령을 실행합니다.
text/status
Status는 Claude Code가 읽은 설정 소스와 잘못된 JSON을 보여 주지만, 각 key의 최종 출처까지 표시하지는 않습니다. 여러 파일에 attribution이 있다면 높은 우선순위부터 검사하세요. cloud 세션에 저장소 정책을 전달하려면 .claude/settings.json이 커밋되어 있어야 합니다. 노트북의 .claude/settings.local.json은 새 cloud clone에 포함되지 않습니다.
검증용 커밋은 임시 브랜치나 테스트 저장소에서 만드세요. 실제로 사용하는 동일한 세션 유형에 무해한 커밋을 요청한 뒤 git show -s --format=fuller로 확인합니다. 로컬 CLI 테스트는 cloud 또는 Remote Control이 만든 링크 동작을 대신 증명하지 못합니다.

기존 히스토리는 위험에 맞춰 다르게 처리하기
공유하지 않은 최신 커밋은 git commit --amend로 메시지를 고칠 수 있습니다. 더 오래된 로컬 커밋은 범위를 확인한 뒤 interactive rebase의 reword를 사용합니다. 둘 다 새 커밋 ID를 만들지만 영향은 로컬에서 통제할 수 있습니다.
이미 공개된 링크가 비인가 사용자에게 열리지 않고 민감정보도 없다면, 히스토리를 그대로 두고 미래 기록만 중단하는 편이 더 안전할 수 있습니다. 단순한 외관 정리를 위한 재작성은 커밋 ID, 서명, 릴리스 참조, 열린 PR, 협업자의 브랜치에 영향을 줍니다.
정책상 공개 히스토리에서 반드시 제거해야 한다면 협업자와 대상 refs, 작업 시간, 복구 절차를 먼저 합의하세요. GitHub의 커밋 메시지 변경 안내는 새 ID 생성과 force push의 협업 영향, 이전 객체 ID로 민감한 메시지가 남을 가능성을 경고합니다.
링크 대상에서 API 키, 개인 키, 고객 데이터 같은 비밀이 실제로 노출됐다면 이는 기여 표시 문제가 아니라 보안 사고입니다. 먼저 세션 가시성을 제한하고 비밀을 폐기하거나 교체한 뒤 Git 정리와 호스팅 지원을 조율해야 합니다. GitHub의 민감정보 제거 문서가 설명하듯 히스토리 재작성만으로 자격 증명이 무효화되지는 않으며, 오래된 clone이 제거한 데이터를 다시 가져올 수도 있습니다.
가장 안전한 순서는 기록 계층 확인, 최소한의 독립 설정 변경, 동일한 세션 유형에서 검증, 실제 가시성과 민감도에 따른 과거 처리입니다. 이렇게 해야 추적 링크를 Git 작성자로 오해하지 않고 불필요한 공유 히스토리 파괴도 피할 수 있습니다.



