# Git worktree en Claude Code: sesiones paralelas
> Cómo usar --worktree, .worktreeinclude, worktree.baseRef y el aislamiento de subagentes. Diferencias con las ramas, cómo limpiar worktrees y errores habituales.
Source: https://ailoot.ai/blog/es/claude-code-git-worktree/
Canonical: https://ailoot.ai/blog/es/claude-code-git-worktree/
Language: es
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-045
Revision: sha256-4e381542593d36ba1482cdeeafe996ba00aa8cf06d16b7eacd0bafba4b552fd8
[La documentación contiene información práctica sobre cómo trabajar con Ailoot](https://ailoot.ai/docs/).
## ¿Qué es un git worktree en Claude Code?
Punto clave
Un Git worktree es un directorio de trabajo separado para otra rama del mismo repositorio. El comando `claude --worktree ` crea automáticamente un worktree en `.claude/worktrees//` e inicia Claude Code allí. Dos terminales → dos sesiones → archivos distintos en el disco, sin interferencias. Está disponible de forma predeterminada en Claude Code v2.0+ y se puede configurar con `.worktreeinclude` para secretos y `worktree.baseRef` para elegir la rama base.
Lanzar varios agentes en paralelo en la misma carpeta es el problema básico del vibe-coding al ritmo de 2026. Los agentes de IA escriben código más rápido de lo que una persona puede seguir quién está tocando qué. Sin aislamiento de archivos, lanzar dos sesiones paralelas de Claude Code en un mismo directorio acaba con una sesión sobrescribiendo el trabajo de la otra.
Git worktree resuelve esto en el nivel del sistema de archivos. Tienes un directorio principal en el que trabajas. El comando `claude --worktree feature-auth` crea la carpeta `.claude/worktrees/feature-auth/` en una rama aparte e inicia Claude Code allí. Los archivos quedan aislados. Los cambios de una sesión no son visibles para la otra hasta que los fusiones explícitamente.
La documentación oficial de Anthropic lo explica así:
Ejecutar cada sesión de Claude Code en su propio worktree significa que las ediciones de una sesión nunca afectan a los archivos de otra. Puedes desarrollar una función en un terminal y corregir un error en otro.
— Documentación de Anthropic, https://code.claude.com/docs/en/worktrees
Una pista para comprobarlo: si alguna vez te ha llegado un commit en el que la mitad de los archivos eran trabajo de otra persona, necesitas un worktree.
## En qué se diferencia git worktree de una rama normal
Punto clave
Un `git checkout` normal cambia la copia de trabajo en la misma carpeta: los archivos anteriores desaparecen del disco hasta que vuelves a la rama. `git worktree add` crea una **segunda carpeta** para otra rama, junto a la primera. Las dos ramas están en el disco al mismo tiempo; pasas de una a otra con un simple `cd`. Por debajo hay un único repositorio `.git`, con historial y remoto compartidos. Solo hay varias copias de trabajo.
El flujo estándar de Git: estás en la rama `main` y ejecutas `git checkout feature-x`; Git sobrescribe los archivos de la copia de trabajo. Un `npm run dev` que esté ejecutándose deja de funcionar porque `package.json` ha cambiado. Guardas los cambios sin commit con `git stash` y esperas a que el IDE vuelva a indexar. Regresas a la rama anterior y todo vuelve a sobrescribirse, así que tienes que volver a hacer stash y pop.
Git worktree ofrece otra opción: en lugar de cambiar **una** carpeta entre ramas, creas una **segunda** carpeta para otra rama. El comando `git worktree add ../project-feature-x feature-x` crea el directorio `../project-feature-x/` con los archivos de la rama `feature-x`. Tu `main` se queda en la carpeta original y el servidor de desarrollo sigue funcionando.
| Parámetro | Rama con `git checkout` | `git worktree add` |
|----|----|----|
| Archivos de la copia de trabajo | Se sobrescriben | Aparecen en una carpeta nueva |
| Trabajo en paralelo en dos ramas | No | Sí |
| Cambios sin commit | Hace falta `git stash` | No hay que hacer nada |
| Velocidad al cambiar | Depende del tamaño de las diferencias | Basta con `cd` |
| Espacio en disco | 1× | N× (una copia de los archivos por rama) |
Antes, había que configurar manualmente el modo worktree en Claude Code: `git worktree add`, luego `cd` y después `claude`; había que repetirlo en cada terminal. La opción `--worktree` (también `-w`) hace las tres cosas con un solo comando.
## Inicia la primera sesión en paralelo: la opción `--worktree`
Punto clave
El comando `claude --worktree feature-auth` crea un worktree en `.claude/worktrees/feature-auth/`, crea la rama `worktree-feature-auth` a partir de `origin/HEAD` e inicia Claude Code allí mismo. No hace falta ejecutar manualmente `git worktree add` ni `cd`. En el terminal de al lado, repite el comando con otro nombre para tener dos sesiones independientes. Si omites el nombre (`claude --worktree`), Claude genera uno aleatorio, como `bright-running-fox`.
Ejemplo mínimo. Abre el primer terminal en la raíz del proyecto:
```bash
claude --worktree feature-auth
```
Claude Code hace tres cosas:
1. Crea `.claude/worktrees/feature-auth/` con una instantánea de `origin/HEAD` (normalmente, tu rama predeterminada).
2. Crea una rama nueva `worktree-feature-auth`.
3. Inicia la sesión en esa carpeta.
Abre un segundo terminal en la misma carpeta raíz del repositorio:
```bash
claude --worktree bugfix-123
```
Listo. Dos sesiones de Claude Code, archivos distintos en el disco y ramas de Git distintas. Si escribes la autenticación en la primera y corriges una prueba fallida en la segunda, físicamente no pueden estorbarse.
Si no quieres escribir un nombre, Claude inventará uno:
```bash
claude --worktree
# → creates something like .claude/worktrees/bright-running-fox/
```
Un consejo para quienes empiezan con Git: añade `.claude/worktrees/` a `.gitignore`. De lo contrario, al ejecutar `git status` en la carpeta principal, verás el contenido de todos los worktrees como archivos sin seguimiento:
```
# .gitignore
.claude/worktrees/
```
Un problema que debes evitar: antes de lanzar `--worktree` por primera vez en un directorio nuevo, entra con un `claude` normal (sin la opción) y acepta el diálogo de confianza del espacio de trabajo. Si no lo haces, la opción falla con un error «trust not accepted», incluso si la combinas con `-p` para el modo sin interfaz.
## Dónde se encuentran los worktrees y cómo localizarlos
Punto clave
De forma predeterminada, todos los worktrees están en `.claude/worktrees//`, junto a la raíz del repositorio. Para ver la lista, ejecuta `git worktree list`. Para entrar manualmente en un worktree, usa `cd .claude/worktrees/feature-auth`. Para cambiar de worktree dentro de una sesión de Claude, pídele que «cambie a otro worktree»; usará la herramienta integrada EnterWorktree. El worktree anterior permanece intacto en el disco.
La ubicación predeterminada es fija: `.claude/worktrees//` en la raíz del repositorio. Si tu proyecto está en `~/dev/my-app/`, el worktree `feature-auth` estará en `~/dev/my-app/.claude/worktrees/feature-auth/`.
Para estructuras no estándar (por ejemplo, si quieres que el worktree esté fuera del repositorio), existe el hook `WorktreeCreate`; hablaremos de él más adelante en la sección sobre SVN y Mercurial.
Dentro de una sesión de Claude, puedes cambiar a otro worktree existente. Solo tienes que decir en el chat: «switch to `.claude/worktrees/bugfix-123`», y Claude llamará a la herramienta `EnterWorktree`. La carpeta actual no se tocará; puedes volver del mismo modo.
El comando estándar de Git muestra una lista de todos los worktrees, incluido el principal y los creados manualmente:
```bash
git worktree list
```
El resultado será parecido a este:
```
/home/user/dev/my-app abc1234 [main]
/home/user/dev/my-app/.claude/worktrees/feature-auth def5678 [worktree-feature-auth]
/home/user/dev/my-app/.claude/worktrees/bugfix-123 9876fed [worktree-bugfix-123]
```
## Copiar `.env` y los secretos: el archivo `.worktreeinclude`
Punto clave
Un worktree es un checkout nuevo. En la nueva carpeta no están los archivos de `.gitignore` (`.env`, `.env.local`, configuraciones locales). Sin ellos, `npm run dev` o `prisma db push` no funcionarán. El archivo `.worktreeinclude` en la raíz del proyecto usa la sintaxis de `.gitignore` e indica a Claude Code qué debe copiar automáticamente a cada worktree nuevo. Se aplica a `--worktree`, a los worktrees de subagentes y a las sesiones de la aplicación de escritorio.
Cuando `--worktree` crea una carpeta nueva, solo incluye lo que se ha guardado en Git. `.env`, que contiene claves de API, y `.env.local`, que contiene la configuración local, aparecen en `.gitignore`, así que no están en el worktree. Por eso, el primer `npm run dev` falla con «MISSING DATABASE_URL».
La solución casera consiste en copiar `.env` manualmente después de cada `--worktree`. Funciona una vez y luego se olvida. La solución de Anthropic es crear un archivo `.worktreeinclude` en la raíz del proyecto con la lista de archivos ignorados por Git que se copiarán automáticamente a cada worktree nuevo.
Crea un archivo `.worktreeinclude` en la raíz del repositorio:
```
.env
.env.local
config/secrets.json
```
La sintaxis es la misma que la de `.gitignore`. Puedes usar patrones glob:
```
.env*
*.local
config/*.json
.vscode/settings.json
```
Anthropic da una regla clara para evitar accidentes:
El archivo usa la sintaxis de gitignore. Solo se copian los archivos que coinciden con el patrón y que también están ignorados por Git. Los archivos bajo seguimiento de Git nunca se duplican.
— Documentación de Anthropic, https://code.claude.com/docs/en/worktrees
En otras palabras, no puedes copiar `package.json` por accidente mediante `.worktreeinclude`: no está en `.gitignore`. Es seguro poner ahí cualquier patrón.
El mismo `.worktreeinclude` funciona en tres modos: el `--worktree` manual, los worktrees automáticos para subagentes (ver más abajo) y las sesiones de la aplicación de escritorio de Claude.
## Worktree a partir de una pull request para revisar código
Punto clave
El comando `claude --worktree "#1234"` obtiene la pull request \#1234 de origin y crea un worktree en `.claude/worktrees/pr-1234/` con la rama de la PR. Puedes pasar la URL completa: `claude --worktree https://github.com/OWNER/REPO/pull/1234`. Es útil para revisar código: abre la PR en su propia carpeta y Claude podrá ejecutar pruebas, leer registros y escribir un comentario mientras el repositorio principal permanece intacto.
Un escenario típico de revisión de código: un compañero ha enviado una PR; tienes que inspeccionar el código, ejecutar pruebas y dejar un comentario. Con un `git checkout pull/1234/head` normal, vuelves a cambiar la copia de trabajo e interrumpes tu sesión activa.
Con la opción `--worktree`, basta con un comando:
```bash
claude --worktree "#1234"
```
Esto es lo que ocurre: Claude Code ejecuta `git fetch origin pull/1234/head`, crea un worktree en `.claude/worktrees/pr-1234/` y cambia a la rama de la PR. Se inicia la sesión. Puedes pedirle de inmediato que «lea el diff, ejecute las pruebas y busque errores lógicos»; mientras Claude trabaja, tu sesión principal en `main` sigue funcionando.
La sintaxis alternativa es la URL completa de la pull request:
```bash
claude --worktree https://github.com/OWNER/REPO/pull/1234
```
En un proyecto real, combinar `claude --worktree "#N"` con tu propio subagente de revisión de código te da una revisión automática en uno o dos minutos. Lánzalo en segundo plano, sigue trabajando en la ventana principal y vuelve al resultado con `claude agents`.
## Rama base: `worktree.baseRef` para `fresh` o `head`
Punto clave
De forma predeterminada, un worktree parte de `origin/HEAD`, el último commit sincronizado del remoto. Es un punto de partida seguro y «limpio». Si quieres incluir commits locales aún no enviados, configura `worktree.baseRef: "head"`. HEAD identifica un commit; las ediciones seguidas sin commit permanecen en la copia original y requieren una transferencia explícita separada. Resulta útil cuando un subagente necesita trabajar sobre tu función actual sin cambiar a main. Solo acepta `fresh` o `head`; no se admiten referencias arbitrarias.
La configuración predeterminada es la siguiente: cada worktree nuevo parte de `origin/HEAD`. La ventaja es empezar desde una base limpia que, con seguridad, coincide con lo que verá CI. El inconveniente es que, si tienes cambios sin commit o varios commits locales por delante del remoto en tu rama actual, no se incluirán en el nuevo worktree.
Para iniciar un worktree desde tu commit HEAD local actual, añade esto a `.claude/settings.json` (o a los ajustes globales):
```json
{
"worktree": {
"baseRef": "head"
}
}
```
Ahora `claude --worktree experimental-feature` parte del `HEAD` local actual. Es útil si tu función ya tiene commits locales sin enviar. No incluye ediciones seguidas aún sin commit. Si el subagente las necesita, consérvalas y transfiérelas expresamente; después inspecciona el diff de destino. No confundas esa transferencia con `.worktreeinclude`, que gestiona archivos locales ignorados.
El ajuste acepta exactamente dos valores: `"fresh"` (= `origin/HEAD`) y `"head"` (= el HEAD local). No admite referencias arbitrarias como `"feature-branch"` ni un hash de commit. Es una limitación deliberada para evitar una explosión combinatoria de opciones.
## Aislar subagentes automáticamente: `isolation: worktree`
Punto clave
Un subagente en Claude Code es un agente especializado que realiza una tarea (revisión de código, refactorización, investigación). Si lanzas varios subagentes en paralelo desde una sesión, trabajan en la misma carpeta de forma predeterminada y pueden sobrescribirse los archivos. Añade `isolation: worktree` al frontmatter del subagente para asignar a cada uno un worktree temporal, que se eliminará al terminar si no ha hecho ningún commit.
Cuando le dices a Claude «lanza tres subagentes: uno lee la base de datos, el segundo revisa la API y el tercero comprueba las pruebas», los tres trabajan en tu copia de trabajo de forma predeterminada. Si solo dos modifican el mismo archivo al mismo tiempo, surge un conflicto. La solución es asignar automáticamente un worktree propio a cada uno.
Método 1: pedirlo verbalmente. Escribe a Claude en la conversación:
```
Usa worktrees para tus agentes.
```
Claude aplicará el aislamiento a todos los subagentes posteriores de esta sesión.
Método 2: configurarlo explícitamente en el propio subagente. En el archivo del subagente (por ejemplo, `.claude/agents/code-reviewer.md`), añade un campo al frontmatter:
```yaml
---
name: code-reviewer
description: Reads the diff and writes code review comments
isolation: worktree
---
Eres un revisor meticuloso. Lee el diff y busca errores de lógica...
```
A partir de entonces, cada vez que se lance este subagente recibirá un worktree temporal en `.claude/worktrees/`. Si no ha escrito nada, la carpeta se elimina automáticamente al terminar. Si hay cambios sin commit, Claude preguntará si quieres conservarlos o eliminarlos.
La rama base de los worktrees de subagentes es la misma que para `--worktree`: de forma predeterminada, `origin/HEAD`; con `worktree.baseRef: head`, el `HEAD` local.
## Matriz de decisión: worktree, `/bg`, subagente o Agent View
Punto clave
Cuatro mecanismos de Claude Code que suelen confundirse. Worktree significa **aislamiento de archivos** (disco). `/bg` es una **sesión en segundo plano** (contexto y tokens). Un subagente es un **agente especializado para una tarea puntual** (prompt y herramientas). Agent View es un **panel de control de todas las sesiones** (interfaz). Se pueden combinar: `/bg` crea un worktree automáticamente, un subagente con `isolation: worktree` se inicia en un worktree temporal y Agent View muestra los tres como filas en una misma lista.
| Herramienta | Qué aísla | Cuándo usarla |
|----|----|----|
| `claude --worktree ` | Archivos (carpeta y rama separadas) | Quieres mantener manualmente N sesiones en paralelo en terminales distintos |
| `/bg` (o `Ctrl+B`) | Contexto y tiempo | Una tarea larga que no quieres que bloquee la ventana actual. Se crea un worktree por debajo |
| Subagente con `isolation: worktree` | Archivos dentro de una sesión | Un prompt asigna tareas a N agentes y necesitas evitar que se sobrescriban entre sí |
| `claude agents` (Agent View) | Nada, es una interfaz | Quieres ver todas las sesiones activas / pausadas / completadas en un mismo panel |
| `/goal` | Gestión de autonomía | Quieres que Claude trabaje hasta que se cumpla una condición, sin que tengas que enviar prompts entre turnos |
Combinaciones habituales:
- **«2 funciones en paralelo, manualmente»** — dos terminales, cada uno ejecutando `claude --worktree`. El caso más sencillo.
- **«Inicia una refactorización durante la noche; cerraré la aplicación»** — `/bg` + `/goal` con una condición de finalización. La sesión funciona independientemente de tu ventana.
- **«Un prompt, tres investigaciones en paralelo»** — tres subagentes con `isolation: worktree`. Cada uno en su propio entorno aislado.
- **«¿Qué está ejecutándose ahora?»** — `claude agents`. Un panel con todas las sesiones y los filtros «running», «blocked» y «done».
## 5 problemas al trabajar con worktrees
Punto clave
Los problemas más habituales: olvidar `.worktreeinclude` y quedarse con un entorno que no funciona; confundir un worktree con una rama normal y perder cambios sin commit; mantener 5+ sesiones en paralelo y olvidar qué hay en cada una; no configurar `cleanupPeriodDays` y dejar que se acumulen carpetas abandonadas; y olvidar el diálogo de confianza en un directorio nuevo, lo que hace que `--worktree` falle con un error.
**1. Has iniciado un worktree, falta `.env` y nada funciona.** Es el problema más habitual. Un worktree es un checkout nuevo sin archivos ignorados por Git. En cuanto configures el modo worktree, añade un archivo `.worktreeinclude` con `.env*` y las configuraciones locales necesarias. Comprueba que el archivo esté en la raíz del repositorio, no en `.claude/`.
**2. Quieres cambiar a la rama principal, ejecutas `cd` hasta la raíz y pierdes tus cambios sin commit en el worktree.** La carpeta raíz y el worktree son dos copias de trabajo **distintas**. Volviste con `cd`; los cambios del worktree se quedaron donde estaban, no desaparecieron. Pero si te confundiste y ejecutaste `git stash` en la carpeta principal creyendo que estabas en el worktree, el stash se creará en la rama principal, no en la que esperabas.
**3. Has iniciado 5 sesiones en paralelo y no recuerdas qué hace cada una.** La documentación de Anthropic advierte explícitamente que la mayoría de los desarrolladores no pueden gestionar cognitivamente más de 2–3 sesiones. Una señal de sobrecarga es abrir Agent View y no poder decir de inmediato qué está haciendo cada agente. Limítate a dos sesiones simultáneas. Si la tarea requiere más, debe coordinarse mediante `/goal` + subagentes, no manualmente.
**4. Los worktrees iniciados con `-p` (modo sin interfaz) no se limpian automáticamente.** El comando `claude --worktree feature-x -p "do thing"` no muestra un aviso interactivo al salir, así que Claude nunca pregunta «¿elimino el worktree?». Estos worktrees se acumulan. Límpialos manualmente: `git worktree remove .claude/worktrees/feature-x`. También puedes usar un script cron que elimine cualquier elemento con más de 7 días.
**5. Diálogo de confianza en una carpeta nueva.** Si abres el repositorio por primera vez y ejecutas `claude --worktree` de inmediato, el comando fallará. Ejecuta `claude` sin opciones, acepta la confianza del espacio de trabajo y sal; después `--worktree` funcionará. Es intencional: así Claude no obtiene acceso al proyecto de otra persona sin el consentimiento del usuario.
## Limpieza: qué se elimina automáticamente
Punto clave
Un worktree de `--worktree` sin cambios (sin commits, sin archivos sin seguimiento ni cambios sin commit) se elimina automáticamente al salir. Si hay cambios, Claude preguntará. Los worktrees de subagentes y `/bg` se eliminan automáticamente mediante el plazo `cleanupPeriodDays` configurado en los ajustes, siempre que estén limpios. Los worktrees de `-p` no se limpian en absoluto: elimínalos manualmente con `git worktree remove`.
La lógica de limpieza depende de lo que hayas hecho en el worktree y de cómo hayas iniciado la sesión. La documentación de Anthropic enumera tres situaciones:
Si el worktree no contiene cambios sin commit, archivos sin seguimiento ni commits nuevos, tanto el worktree como su rama se eliminan automáticamente al salir de la sesión. Si la sesión tiene un nombre, Claude pregunta en lugar de eliminarlo para que puedas conservar el worktree para más adelante.
— Documentación de Anthropic, https://code.claude.com/docs/en/worktrees
Situación 1: entraste, no hiciste nada y saliste; el worktree se eliminó.
Situación 2: trabajaste un poco y no hiciste commit; al salir, Claude preguntará «¿conservar o eliminar?». «Conservar» guarda la carpeta y la rama para más adelante. «Eliminar» borra el directorio **junto con** los cambios sin commit y los commits nuevos. Es destructivo: no pulses «eliminar» por costumbre.
Situación 3: iniciaste con `-p` (modo sin interfaz) y el comando terminó. El worktree permanece. Límpialo manualmente:
```bash
git worktree remove .claude/worktrees/feature-x
```
Además, la limpieza en segundo plano elimina automáticamente los worktrees de subagentes y sesiones `/bg` si tienen más de `cleanupPeriodDays` días (un ajuste que normalmente es de 30 días de forma predeterminada) **y** no contienen trabajo sin guardar. La limpieza automática no toca los worktrees de `--worktree`; son responsabilidad tuya.
## Alternativas para SVN, Perforce y Mercurial: el hook `WorktreeCreate`
Punto clave
El modo worktree utiliza `git worktree` de forma predeterminada. Para SVN, Perforce, Mercurial y otros VCS, puedes conectar tu propio mecanismo mediante los hooks `WorktreeCreate` y `WorktreeRemove` en los ajustes de Claude Code. El hook recibe el nombre por stdin, debe imprimir la ruta al directorio creado y terminar con el código 0. Si usas tu propio hook, no se procesa `.worktreeinclude`; tendrás que copiar los archivos locales dentro del hook.
Si el repositorio usa Subversion o Mercurial, la opción `--worktree` no funcionará directamente. Anthropic ofrece un punto de extensión mediante dos hooks: `WorktreeCreate` (crea una copia aislada) y `WorktreeRemove` (la elimina).
Ejemplo de hook SVN de la documentación oficial:
```json
{
"hooks": {
"WorktreeCreate": [
{
"hooks": [
{
"type": "command",
"command": "bash -c 'NAME=$(jq -r .name); DIR=\"$HOME/.claude/worktrees/$NAME\"; svn checkout https://svn.example.com/repo/trunk \"$DIR\" >&2 && echo \"$DIR\"'"
}
]
}
]
}
}
```
El hook lee el nombre del worktree por stdin (`{ "name": "feature-auth" }`), ejecuta `svn checkout` en un directorio calculado de antemano e imprime la ruta por stdout; Claude Code la utiliza como directorio de trabajo de la nueva sesión.
Una advertencia importante: si usas tu propio hook, no se utiliza `.worktreeinclude`. Si necesitas `.env` u otros archivos ignorados por Git en la carpeta nueva, cópialos dentro del propio script del hook.
## Qué viene después: tres mecanismos de paralelismo relacionados
Punto clave
Worktree proporciona aislamiento de archivos. `/bg` proporciona aislamiento de contexto y tokens. Subagent proporciona aislamiento de tareas y herramientas. `/goal` proporciona autonomía hasta que se cumpla una condición. Cada mecanismo resuelve un problema por separado. Juntos permiten mantener 3–5 tareas en paralelo sin colapso cognitivo. Después, tiene sentido explorar las guías relacionadas con el modo autónomo, los subagentes personalizados y los flujos de trabajo dinámicos mediante los enlaces de abajo.
Worktree proporciona aislamiento de archivos. `/bg` proporciona aislamiento del contexto. Los subagentes proporcionan aislamiento de tareas. Cada mecanismo resuelve un problema por separado. Juntos ofrecen una forma de trabajar en tres a cinco tareas en paralelo sin colapso cognitivo. Estas son las habilidades que sustentan el vibe-coding avanzado en 2026.
Este tema enlaza de forma natural con otros tres: [cómo configurar un agente autónomo con `/goal` y Agent View](https://ailoot.ai/blog/es/claude-code-goal-agent-view/), [cómo crear tus propios subagentes para tus tareas](https://ailoot.ai/blog/es/claude-code-subagents/) y [cómo lanzar cientos de agentes mediante Dynamic Workflows](https://ailoot.ai/blog/es/claude-code-dynamic-workflows/).
### Fuentes
- [Ejecutar sesiones en paralelo con worktrees - Documentación de Claude Code](https://code.claude.com/docs/en/worktrees)
- [Crear subagentes personalizados - Documentación de Claude Code](https://code.claude.com/docs/en/sub-agents)
- [Registro de cambios de Claude Code (mayo-junio de 2026)](https://code.claude.com/docs/en/changelog)
- [Ejecutar agentes en paralelo - Documentación de Claude Code](https://code.claude.com/docs/en/agents)
- [Agent View - Documentación de Claude Code](https://code.claude.com/docs/en/agent-view)
- [Página de manual de git worktree](https://git-scm.com/docs/git-worktree)
[Abrir Ailoot](https://ailoot.ai/).
## Preguntas sobre Claude Code
### ¿baseRef head copia cambios sin commit al nuevo worktree?
No. Parte del commit HEAD local actual, incluidos commits ausentes del remoto. Las ediciones seguidas sin commit permanecen en la copia original; transfiere expresamente el WIP necesario e inspecciona el nuevo worktree.
### ¿Por qué falta mi .env en un worktree nuevo?
Es una copia de trabajo nueva y los archivos locales ignorados por Git no aparecen. `.worktreeinclude` de Claude Code enumera los ignorados que deben copiarse; un hook WorktreeCreate personalizado debe hacerlo por sí mismo. Incluye solo lo que necesite la tarea.
## Ailoot · La empresa y su cartera de proyectos
Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI.
La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes.
Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.