Contenido

El agent view de Claude Code (se abre con claude agents) es el sitio desde el que lanzas sesiones independientes una tras otra en segundo plano y las gestionas todas desde una sola pantalla. En palabras de la documentación oficial, sirve para "hacer dispatch de muchas sesiones de Claude Code y gestionarlas desde una única pantalla" (Manage multiple agents with agent view).

Este artículo se ciñe a la mecánica y al modelo de seguridad. El peligro real no es "que la IA se descontrole", sino poner diez sesiones en fila sin saber hasta dónde llega el aislamiento ni con qué permisos están corriendo mientras tú miras hacia otro lado. La versión corta: el aislamiento está construido con verdadero cuidado — pero hay tres cosas que se escapan de él. Ahí es donde conviene poner la atención.

📌 De dónde salen estos datos: cada comportamiento, número de versión y nombre de ajuste que aparece más abajo se comprobó contra la documentación oficial a fecha de 9 de agosto de 2026. Agent view es una research preview y requiere Claude Code v2.1.139 o posterior. Las funciones en preview se mueven, así que comprueba tu propia build con claude --version y confirma los detalles en la documentación actual.

🔀 Si has llegado aquí buscando "Dispatch". Claude tiene dos funciones distintas con nombres confusamente parecidos. Dispatch, el del panel lateral de la aplicación de escritorio, es la función que te permite escribirle a Claude desde el móvil para que trabaje en tu propio ordenador, y no es de lo que trata este artículo — de esa se ocupa cómo funciona Dispatch y hasta qué punto es seguro. Este artículo va de agent view, una función de terminal de Claude Code; los nombres chocan porque la documentación oficial llama "dispatch" a la operación que se realiza ahí.

1. Qué es agent view — la operación que la documentación llama "dispatch"

Empecemos por fijar el nombre. Dentro de Claude Code, "dispatch" es el nombre de una operación que realizas en agent view, no el de una función aparte que se llame así. La documentación oficial lo formula de esta manera.

"Agent view, que se abre con claude agents, es una única pantalla que muestra todas tus sesiones en segundo plano: qué está en marcha, qué está esperando a que respondas y qué ha terminado." (Agent view)

La documentación es igual de clara sobre cuándo recurrir a él: cuando tienes varias tareas independientes, quieres delegarlas, quieres ver su estado de un vistazo y quieres intervenir solo si hace falta. Un arreglo de un bug, la revisión de un PR, la investigación de un test inestable — lanza esas tres como tres filas, sigue con lo tuyo en otra ventana y ve a mirar cuando una fila pase a "te necesita".

✅ Trabajo que le va bien

Tareas independientes entre sí y que no necesitas vigilar mientras avanzan. Trabajo en el que basta con recibir el resultado al final y puedes estar a otra cosa mientras tanto.

❌ Trabajo que no

Todo aquello cuyo rumbo hay que volver a decidir a mitad de camino, todo lo que se pelea por los mismos archivos y todo lo que contiene una acción irreversible (un despliegue, la base de datos de producción, enviar algo al exterior).

2. Un prompt es una sesión entera, no un añadido a la anterior

Esto es lo primero que pilla a la gente desprevenida. La documentación lo deja escrito: cada prompt que escribes aquí arranca su propia sesión nueva. Escribe un segundo prompt, pulsa Enter y obtienes una segunda sesión al lado de la primera, no una instrucción más añadida a ella.

Si escribes "una cosa más sobre lo anterior" por puro reflejo de chat, no has añadido una nota: has añadido un trabajo. Es diseño y no accidente, porque agent view existe precisamente para poner tareas independientes en fila. Cuando de verdad quieras mandar una instrucción adicional, la mandas desde el peek panel (el panel de vistazo) que se describe más abajo.

Acción Qué ocurre
Prompt en el campo de entrada → Enter Arranca una sesión nueva (se van acumulando en paralelo)
Space Abre el peek panel. Te da la última salida o la pregunta que está esperando, no la transcripción completa
Responder en el peek panel → Enter Contesta a esa sesión sin salir de agent view
→ o Enter (con una fila seleccionada) Entra en esa sesión (attach)
Ctrl+X La detiene. Púlsalo otra vez y la borra (lo que lleva directo a la trampa de la sección 6)
Ctrl+S / Ctrl+T / Ctrl+R Agrupar (por estado o por directorio) / fijar / renombrar

Una cosa más: los subagents y compañeros de equipo que una sesión se genera por su cuenta no aparecen como filas independientes. Lo que lista la pantalla son solo las unidades de las que tú hiciste dispatch.

3. Cómo funciona el aislamiento — se muda a un worktree antes de escribir

Aquí vive el modelo de seguridad. Una sesión en segundo plano se muda a un git worktree propio antes de editar ningún archivo. La descripción oficial dice así.

"Toda sesión en segundo plano empieza en tu directorio de trabajo, tanto si se lanzó desde agent view como si se lanzó con /bg o claude --bg. Antes de editar archivos, Claude traslada la sesión a un git worktree aislado bajo .claude/worktrees/. De ese modo, las sesiones paralelas leen el mismo checkout pero cada una escribe en el suyo." (Agent view)

Lo que hace que este diseño funcione es que las lecturas se comparten y las escrituras se separan. Las sesiones paralelas pueden leer el código de las demás, así que sus premisas no se van desviando, mientras que sus escrituras no pueden chocar. Tres sesiones corriendo en el mismo directorio y machacándose los archivos unas a otras — la peor versión de este accidente — resulta estructuralmente imposible.

Y luego está la frase que más importa. "Una vez que una sesión está en un worktree, Claude Code bloquea las ediciones de archivos y los comandos que alcanzarían el checkout principal, tanto para esa sesión como para cualquier subagent que genere." El aislamiento lo heredan los hijos. Si una sesión de la que hiciste dispatch invoca internamente a cinco subagents, los cinco están dentro del mismo muro.

4. Las tres comprobaciones que sostienen el aislamiento

La documentación concreta qué significa "bloquea". Hay tres tipos de comprobación.

1. Ediciones de archivos

Bloquea Edit, Write y NotebookEdit dirigidos a una ruta dentro del checkout principal.

2. Directorio de trabajo del comando

Bloquea los comandos cuyo directorio de trabajo se resuelve al checkout principal y los comandos de los que no se puede verificar que se queden fuera de él.

3. Redirigir git

git -C, --git-dir, GIT_DIR, GIT_WORK_TREE, un cd antes de git — todos quedan cortados.

Cerrar la tercera es señal de un trabajo serio. No es solo "no escribas en main", sino también "no engañes a git para que apunte a main". Y la decisión se toma del lado seguro: un comando que no se puede verificar no se ejecuta.

⚠️ Dicho esto, no es un muro a nivel de sistema operativo. Las tres comprobaciones funcionan inspeccionando qué pide una llamada a una herramienta, no confinando un proceso. Lo que protegen es el checkout principal del mismo repositorio, y los archivos de fuera del repositorio, más la red, quedan fuera del alcance de las tres.

La documentación también afirma sin rodeos que a los comandos de PowerShell solo se les aplica la comprobación 2, la del directorio de trabajo. Si PowerShell es tu shell principal en Windows, no cuentes con la tercera protección. Confinar el proceso en sí no es tarea del worktree, sino del sandbox.

5. De dónde salen los permisos

Mientras tú no estás mirando, ¿bajo qué modo de permisos está corriendo esa sesión? Poner sesiones en fila sin tener respuesta a esa pregunta es lo más peligroso que puedes hacer aquí.

La regla oficial no admite dudas. Cuando haces dispatch desde el campo de entrada de agent view, o ejecutas claude --bg desde una shell, se usa el defaultMode de los ajustes de ese directorio. Si de lo que hiciste dispatch es de un subagent, se usa en su lugar el permissionMode de su frontmatter.

Dicho de otro modo, los permisos no se eligen sobre la marcha: se heredan de tu configuración. Cuanto más laxo sea tu defaultMode habitual en settings.json, más literalmente cierto se vuelve que en el momento de hacer dispatch nacen diez sesiones desatendidas con permisos laxos. Poner en orden tus modos de permisos y tus reglas de permisos antes de nada es un requisito previo, no un detalle.

Donde debe detenerse, eso sí, se detiene como es debido. Cuando una sesión necesita algo que solo tú puedes darle — la respuesta a una pregunta, una decisión de permiso, la siguiente instrucción — la fila pasa a "Needs input" (a la espera de tu entrada). Ese estado es el único punto de control que te queda. Por eso agent view no es "una pantalla donde amontonas cosas y te vas", sino "una pantalla a la que vuelves para recoger las filas que esperan tu entrada".

6. Las trampas que es fácil pasar por alto

El aislamiento está construido con cuidado. Aun así, hay tres cosas que se escapan de él. Es la parte que muerde en el trabajo real.

1. Un "no volver a preguntar" se sale del worktree

Según la documentación, elegir "Sí, no volver a preguntar" para un comando de Bash en una sesión con worktree guarda esa regla en el .claude/settings.local.json del checkout principal. El resultado: se aplica en el checkout principal y en todos los demás worktrees, y sobrevive a la eliminación del worktree donde se creó.
Es decir, una única decisión de permiso tomada dentro de un lugar aislado se convierte en configuración permanente fuera de él. Un "no volver a preguntar" pulsado mientras mirabas hacia otro lado, dentro de lo que creías un espacio de trabajo desechable, queda vigente a partir de ahí. No recurras a la ligera a "no volver a preguntar" cuando el peek panel de una sesión despachada te pida permiso.

2. Borrar una sesión se lleva por delante el trabajo sin commitear

Está dicho sin rodeos en las limitaciones oficiales: "Los worktrees creados por Claude se eliminan junto con la sesión cuando la borras en agent view. Haz commit de tus cambios antes de borrar una sesión que haya editado archivos en su propio worktree."
Ctrl+X es detener a la primera pulsación, borrar a la segunda. Púlsalo dos veces mientras haces limpieza de una sesión terminada y el resultado se va con ella. "Terminado" y "recogido" no son lo mismo — una vez tengas el resultado, haz commit o merge antes de borrar.

3. .worktreeinclude reparte tus secretos a todos los worktrees

Un worktree es un checkout nuevo, así que un .env ignorado por git no está dentro. Como sin él no arranca nada, lo apuntas en .worktreeinclude y se copia automáticamente cada vez que se crea un worktree nuevo.
Cómodo — pero, dado la vuelta, significa que por cada sesión de la que haces dispatch aterriza en disco una copia más de tus credenciales. Si vas a ejecutar esto en paralelo, lo sensato es repartir claves de desarrollo, no de producción.

Se enumeran oficialmente otras tres limitaciones. La cuota se consume de forma multiplicativa ("ejecutar diez agentes en paralelo gasta tu cuota unas diez veces más rápido que ejecutar uno"). Las sesiones se ejecutan en local — sobreviven a la suspensión, pero apagar la máquina las detiene. Y el hecho mismo de que esto sea una research preview.

7. Cuál elegir — hay cuatro formas de paralelizar

La documentación oficial ordena la paralelización en cuatro enfoques. El dispatch (agent view) es solo uno de ellos, así que elegir mal te sale caro sin más.

Enfoque Quién lleva la batuta Cuándo elegirlo
Subagents Claude delega dentro de una misma conversación y recoge el resultado No quieres que la salida del trabajo lateral (resultados de búsqueda, logs, archivos) ensucie el contexto principal
Agent view (dispatch) Tú delegas y vuelves a mirar más tarde Varias tareas independientes. Este artículo. Research preview
Agent teams Claude planifica, asigna y supervisa Quieres que el reparto de trabajo y la sincronización te los resuelvan. Experimental, desactivado por defecto. Tiene su propio artículo
Flujos de trabajo dinámicos El plan lo lleva un script Una auditoría de todo el código, una migración de 500 archivos — una escala que ningún turno único puede dirigir. Y cuando hay que contrastar resultados entre sí

La línea divisoria es quién lleva la batuta. Si se termina dentro de una conversación, subagents. Si lo lanzas tú y lo recoges luego, agent view. Si quieres que lo lleve Claude, agent teams. Si la escala pide un procedimiento fijo en vez de criterio sobre la marcha, flujos de trabajo dinámicos.

Los worktrees, por cierto, están planteados no como una forma de paralelizar, sino como una herramienta de aislamiento. Agent view los usa de forma automática. Para las sesiones paralelas que arrancas tú, se nombra uno explícitamente, como en claude --worktree <nombre>.

8. Una rutina para llevar esto con seguridad

Antes de hacer dispatch

  • Comprueba el defaultMode de ese directorio. Se convierte, tal cual, en el nivel de permisos de una sesión que nadie vigila
  • No delegues trabajo que contenga acciones irreversibles. Los despliegues, la base de datos de producción y los envíos al exterior van en una sesión que estés mirando
  • ¿Son las tareas realmente independientes? Si dependen de la misma decisión de diseño, resuélvela primero y delega después
  • ¿Qué tienes en tu .worktreeinclude? Tus claves se copian una vez por cada sesión que pongas en fila

Mientras corren

  • Vuelve a por las filas en "Needs input". Ese es el único punto de control
  • Cuando te pidan permiso, no elijas "no volver a preguntar". Esa decisión sobrevive al worktree
  • El paralelismo se traduce directamente en cuota. Diez a la vez la vacían diez veces más rápido

Cuando terminen

  • Haz commit antes de borrar. El segundo Ctrl+X borra, y el contenido del worktree se va con él
  • No des los resultados por buenos. Todo lo que corriste en paralelo sumó una afirmación más sin verificar

El último punto merece subrayarse como regla práctica. Paralelizar aumenta la cantidad total de revisión. Diez trabajos vuelven con diez preguntas de "¿esto es cierto de verdad?" pegadas; la comprobación no se paraleliza junto con el trabajo. El techo de cuántos despachas lo fija cuántos resultados eres capaz de verificar.

Resumen

Dispatch es el acto de arrancar una sesión independiente en segundo plano desde agent view (claude agents), y es una research preview (v2.1.139 o posterior). Un prompt se convierte en una sesión, nunca en un añadido a la anterior.

El corazón del modelo de seguridad es el aislamiento por worktree. Antes de escribir, la sesión se muda a .claude/worktrees/, y a partir de ahí las lecturas se comparten mientras las escrituras se separan. Las ediciones, comandos y redirecciones de git que alcanzarían el checkout principal quedan cortados por tres comprobaciones, y esa protección la hereda cualquier subagent que la sesión genere.

Pero hay tres cosas que salen del aislamiento. Un "no volver a preguntar" se guarda en el lado principal, se aplica en todos los worktrees y sobrevive a borrar el worktree. Borrar una sesión destruye el trabajo sin commitear. .worktreeinclude copia tus secretos una vez por worktree. Y como un worktree no es un muro a nivel de sistema operativo, todo lo que queda fuera del repositorio y la red están desprotegidos — de eso se encarga el sandbox.

FAQ

Q1. ¿Existe realmente una función llamada "Dispatch" en Claude Code?

No como nombre de una función independiente. Dispatch es el nombre de una operación dentro de agent view. La documentación oficial describe agent view como la función que te permite "hacer dispatch de muchas sesiones de Claude Code y gestionarlas desde una única pantalla". El comando que lo abre es claude agents.

Q2. ¿Son /agents y claude agents lo mismo?

No lo son. La documentación avisa de ello directamente: pese al nombre parecido, /agents no es claude agents. claude agents es el comando de shell que abre agent view. /agents, desde la v2.1.198, ya no abre ningún panel: se limita a decirte dónde viven tus archivos de definición de subagents.

Q3. ¿Puede una sesión despachada romperme mi copia de trabajo principal?

En lo que respecta al checkout principal del mismo repositorio, estás protegido de forma estructural. Las ediciones de archivos, los directorios de trabajo de los comandos y las redirecciones de git quedan bloqueados por las tres comprobaciones, y la misma protección cubre a cualquier subagent que la sesión genere. Ahora bien, los archivos de fuera del repositorio y la red quedan fuera de alcance, y bajo PowerShell solo se aplica la comprobación del directorio de trabajo.

Q4. ¿Qué le hace al coste correrlas en paralelo?

Sube más o menos en proporción al número. Las limitaciones oficiales lo dicen así: ejecutar diez agentes en paralelo gasta tu cuota unas diez veces más rápido que ejecutar uno. Que sea en segundo plano no lo hace barato.

Q5. ¿Puedo borrar una sesión sin más una vez ha terminado?

Primero commit, luego borrar. La documentación afirma que los worktrees creados por Claude se eliminan junto con la sesión cuando la borras en agent view. Ctrl+X detiene a la primera pulsación y borra a la segunda. Haber recibido el resultado no es lo mismo que haberlo incorporado.

Q6. ¿Puedo elegir el modo de permisos cada vez que hago dispatch?

Sobre la marcha no. Se usa el defaultMode de los ajustes de ese directorio — o, si despachaste un subagent, el permissionMode de su frontmatter. Si tu defaultMode habitual es laxo, esa laxitud es la que se ejecuta sin nadie delante. Repasa tus ajustes de permisos antes de empezar a usar dispatch.

Q7. ¿En qué se diferencia esto de los subagents?

La diferencia está en quién lleva la batuta. Con subagents, Claude delega dentro de una misma conversación y devuelve el resultado a esa conversación. Con agent view, tú delegas tareas independientes y recoges los resultados después. Los subagents que genera una sesión no se muestran como filas en agent view.

Q8. ¿Qué pasa si cierro el portátil?

Se detienen. Las limitaciones oficiales dicen que las sesiones en segundo plano se ejecutan en tu máquina: sobreviven a la suspensión, pero apagar la máquina las detiene. Nada corre en la nube, así que esta no es la herramienta para lanzar un trabajo largo por encima del muro y marcharte a casa.

Artículos relacionados