# Enlaces de sesión de Claude Code y atribución en Git: controlarlos sin confundir autoría

> Distingue Claude-Session, Co-Authored-By y la identidad de autor/confirmador de Git; audita el repositorio, aplica el ajuste correcto y decide si tocar el historial.

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

Un commit puede mostrar `Claude-Session: https://claude.ai/code/session_...`, una línea `Co-Authored-By` y, además, el autor que presenta la interfaz de GitHub. Parecen tres versiones de la misma atribución, pero no lo son. La URL y el coautor son tráileres del mensaje del commit; Git guarda por separado los campos `author` y `committer` —autor y confirmador— dentro del objeto.

Claude Code también los configura por separado. `attribution.commit` controla el texto añadido al mensaje del commit, `attribution.pr` controla el texto de la descripción del pull request y `attribution.sessionUrl` controla el enlace a la sesión. Según la [referencia oficial de Git y atribución](https://code.claude.com/docs/en/settings-reference#git-and-attribution), comprobada el 31 de agosto de 2026, `sessionUrl` vale `true` por defecto cuando una sesión en la nube o de Remote Control crea un commit o abre un PR.

## Averigua qué identidad estás viendo

Este mensaje contiene dos tráileres:

```text
Fix token refresh race

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

Ninguno reemplaza automáticamente el autor principal del objeto Git. Un servicio de alojamiento puede interpretar `Co-Authored-By` y mostrar otro avatar, pero los campos `author` y `committer` siguen existiendo con sus propios nombres y correos.

Inspecciona ambas capas en un commit concreto:

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

Las dos primeras líneas pertenecen al objeto; después aparece el mensaje completo. Cambiar la atribución de Claude Code no modifica la identidad de commits anteriores, las firmas, `user.name` ni `user.email`.

Hay otra URL de Claude que sirve para algo distinto. Un enlace `claude-cli://` abre una nueva sesión local con un directorio o prompt preparado. No es el enlace HTTPS a una conversación que aparece como `Claude-Session`. La [documentación sobre deep links](https://code.claude.com/docs/en/deep-links) describe ese mecanismo independiente.

![Referencia en español de las tres capas de atribución, inspección de un commit, búsquedas de solo lectura, claves independientes, ámbitos de configuración y decisiones sobre el historial](https://www.aifreeapi.com/posts/es/claude-code-session-url-git-attribution/img/audit-settings-map.webp)

## Audita todas las referencias sin abrir la conversación

Busca primero los tráileres de sesión en todos las referencias accesibles del clon:

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

Enumera aparte los coautores declarados:

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

La referencia oficial de [`git log`](https://git-scm.com/docs/git-log) separa estas consultas: `--grep` filtra el mensaje, `--author` y `--committer` filtran las cabeceras de identidad, y `%(trailers:...)` interpreta los tráileres. Por eso, encontrar `Co-Authored-By` no demuestra que ese nombre ocupe el campo author.

Si la primera orden no devuelve nada, no hay coincidencias en las referencias alcanzables de este repositorio local. No demuestra que nunca existieran en una rama remota eliminada, un fork, otro clon o un objeto antiguo del proveedor. Para prevención cotidiana no hace falta investigar indefinidamente; amplía el inventario solo cuando exista un incidente confirmado.

La URL tampoco decide por sí sola quién puede ver la conversación. Las [reglas de uso compartido de sesiones en la nube](https://code.claude.com/docs/en/claude-code-on-the-web#work-with-sessions) distinguen las opciones de Team/Enterprise y Pro/Max, el inicio de sesión del receptor y las comprobaciones de acceso al repositorio. En un commit público cualquiera puede leer el texto de la URL, pero la visibilidad del destino es un control separado que debe probarse con la cuenta receptora prevista.

## Conserva la atribución y elimina solo el enlace

Si el equipo quiere informar del uso de Claude, pero no guardar un acceso a la conversación, basta con un ajuste mínimo:

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

Este valor no elimina `Co-Authored-By` ni el texto del PR. Para omitir tanto las atribuciones como el enlace, configura las tres opciones:

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

También puedes sustituir las cadenas vacías por una declaración propia del equipo. `commit` admite texto y tráileres de Git; `pr` es texto normal de la descripción. Un campo no definido conserva el texto estándar que use esa versión de Claude Code.

No diseñes una configuración nueva alrededor de `includeCoAuthoredBy`. Anthropic lo marca como obsoleto desde v2.0.62. Se sigue leyendo por compatibilidad, pero el objeto `attribution` expresa por separado el commit, el PR y la URL. Un Boolean antiguo no comunica con claridad “mantener el coautor, eliminar solo el enlace”.

## Elige el ámbito antes de guardar el JSON

| Decisión | Archivo | A quién afecta |
|---|---|---|
| Preferencia personal para todos los proyectos | `~/.claude/settings.json` | Al usuario actual |
| Política común del repositorio | `.claude/settings.json` | Al equipo y a los clones en la nube si se guarda en Git |
| Prueba o excepción para este clon | `.claude/settings.local.json` | Solo a la persona y repositorio locales |
| Regla obligatoria de empresa | Ajustes administrados | A los usuarios cubiertos por la política administrativa |

La [documentación de ámbitos de Claude Code](https://code.claude.com/docs/en/settings) establece, para valores ordinarios, este orden de prioridad: ajustes administrados, línea de comandos, proyecto local, proyecto compartido y usuario. Un archivo de usuario perfectamente válido puede parecer ignorado si una capa superior define el mismo ajuste.

Después de editar, inicia una sesión nueva y ejecuta:

```text
/status
```

Status muestra las fuentes cargadas y los errores de JSON o validación. No atribuye cada clave a un archivo concreto; si varios archivos contienen `attribution`, revísalos de mayor a menor prioridad. Para una sesión nueva en la nube, la política compartida debe estar confirmada en `.claude/settings.json`. El archivo local de tu ordenador no aparece mágicamente en un clon limpio.

Haz la comprobación en una rama temporal o un repositorio de prueba. En un repositorio de prueba o rama temporal, pide al mismo tipo de sesión que cree un commit inocuo y examínalo con `git show -s --format=fuller`. Una prueba hecha solo en el terminal local no valida el comportamiento de las sesiones en la nube o de Remote Control si ese era el origen del enlace.

![Mapa en español que distingue tráileres e identidad Git y relaciona los ajustes commit pr sessionUrl, el ámbito, la verificación y el nivel de riesgo de los commits existentes](https://www.aifreeapi.com/posts/es/claude-code-session-url-git-attribution/img/history-risk-decision.webp)

## Trata el historial según el riesgo, no según la estética

El último commit no compartido se puede corregir con `git commit --amend`. Para commits locales anteriores, un rebase interactivo permite seleccionar `reword`. Ambos crean identificadores nuevos, pero el impacto permanece bajo control local.

Si el commit ya está publicado, el enlace no abre la sesión a terceros y no contiene información sensible, suele ser menos arriesgado conservar la historia y evitar futuras inserciones. Reescribir por uniformidad visual cambia IDs, rompe firmas, altera referencias de versiones, afecta PR abiertos y obliga a colaboradores a realinear sus ramas.

Si una política exige retirar el texto de la historia publicada, coordina primero las referencias afectadas, el momento del cambio y la recuperación. La guía de GitHub [cómo cambiar un mensaje de commit](https://docs.github.com/en/pull-requests/how-tos/commit-changes/changing-a-commit-message) advierte que cada cambio crea un ID nuevo, un force push puede interrumpir a otras personas y un mensaje sensible antiguo podría seguir accesible mediante su identificador anterior.

Si la sesión era visible y mostró una clave API, una clave privada, datos de clientes u otro secreto, ya no es una preferencia de atribución. Restringe la sesión y revoca o rota el secreto antes de limpiar Git. Después coordina la reescritura y el soporte del proveedor. La guía de GitHub [cómo retirar datos sensibles de un repositorio](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository) explica por qué reescribir no invalida una credencial y cómo un clon antiguo puede reintroducir datos.

Identifica primero si quieres cambiar el enlace, la atribución o la autoría. Aplica el ajuste correspondiente y compruébalo en el mismo tipo de sesión que creó el commit. Para el historial existente, decide según quién puede verlo y si contiene información sensible; así conservas la trazabilidad sin reescribir más de lo necesario.