Bloom, la app de Spatie para correr Claude Code y Codex en paralelo en el Mac

Bloom es una aplicación nativa de macOS, hecha por Spatie, que corre los agentes de código que ya tienes instalados dando a cada tarea su propio git worktree y su propia rama. Es gratuita, es open source con licencia MIT, y no trae ningún agente propio: ejecuta los binarios claude o codex de tu máquina con la sesión que ya tienen iniciada.

El nombre está muy repetido, así que conviene fijarlo: hablo de Bloom de Spatie, dominio runbloom.app, repositorio github.com/spatie/bloom, que no tiene relación con bloom-mcp ni con los otros proyectos homónimos. Los propios autores tuvieron que lidiar con esto: el cask de Homebrew se llama spatie-bloom porque el cask bloom ya lo ocupaba un gestor de ficheros.

El problema que resuelve, que es de git y no de IA

Si has intentado correr dos agentes a la vez sobre el mismo repositorio, ya conoces el fallo: comparten el mismo directorio de trabajo, así que se sobrescriben ficheros, se pisan las ramas y acabas con un git status imposible de leer. Lo que hace falta ahí es un directorio por tarea.

Eso es exactamente lo que hace git worktree, y es el mecanismo sobre el que está construida toda la aplicación. Un repositorio, un solo historial y un solo almacén de objetos, pero N directorios en disco, cada uno con su rama, que no pueden ver los ficheros de los otros. Tu checkout de siempre se queda donde estaba, intacto.

Bloom llama workspace a cada uno de esos worktrees. Describes una tarea y la aplicación corta la rama, corta el worktree bajo ~/bloom/workspaces.noindex, copia los ficheros que hayas indicado, ejecuta tu script de setup y arranca un agente dentro. Ese sufijo .noindex mantiene Spotlight fuera, que es justo lo que necesitas cuando doce worktrees del mismo proyecto tienen cada uno su copia de vendor y .build.

Es la misma idea de aislamiento que ya cubrimos al hablar de CLIs para orquestar agentes, pero resuelta desde una ventana de escritorio en vez de desde la terminal.

Qué es técnicamente

Está escrito en Swift sobre los frameworks del sistema, con AppKit y SwiftUI, y con solo dos dependencias: SwiftTerm para los paneles de terminal y Sparkle para las actualizaciones. No hay cuenta que crear. El panel de navegador usa un web view, que es lo único que hay de web en la aplicación.

No trae .xcodeproj, a propósito: abres Package.swift en Xcode y tienes targets, esquemas, depurador y previsualizaciones.

Instalación y requisitos duros

Bloom necesita macOS 26 o posterior, y ese es el requisito que decide si puedes probarlo.

brew install --cask spatie/bloom/spatie-bloom

También hay imagen de disco en runbloom.app. Cada versión va firmada, notarizada y grapada, y se publica a un appcast de Sparkle, así que una copia instalada te ofrece cada nueva versión según sale. La última publicada en ese appcast, al escribir esto, es la 1.9.1, del 9 de septiembre de 2026.

Y lo que tiene que estar en tu PATH:

• claude (Claude Code) o codex, al menos uno de los dos. Cada chat elige uno, así que un mismo workspace puede tener conversaciones con los dos a la vez.
• git.
• gh, el CLI de GitHub, solo para las funciones de pull request y de checks. El resto funciona sin él.

Cursor (cursor-agent) y OpenCode (opencode) se detectan y aparecen en la pantalla de ajustes de agentes, pero ninguno tiene backend en Bloom, así que no se ofrecen al iniciar un chat. La propia documentación lo declara así.

La ventana

Una barra lateral con los proyectos y sus workspaces, la conversación del agente en el centro, y lo que ha cambiado a la derecha. A partir de ahí:

Paneles. Un workspace tiene pestañas y una pestaña se puede dividir. Un panel es un chat, una terminal situada dentro del worktree, o un navegador. Eso permite leer el servidor de desarrollo que arrancó el script de setup al lado de la conversación que lo está cambiando. Con tmux instalado, las terminales pueden seguir corriendo después de cerrar la aplicación.

Revisión. El inspector lista los ficheros que cambió el workspace y muestra el diff contra el merge base, con resaltado de sintaxis. Puedes comentar una línea, y ese comentario se incluye en el siguiente turno del agente. También puedes editar el fichero tú mismo; si el agente lo cambió desde que lo abriste, Bloom se niega a sobrescribir la versión más nueva.

Envío. Con gh instalado, el pull request se abre, se ven sus checks y se hace merge desde la misma ventana. El merge manda al agente un prompt que puedes editar, y como el agente ya tiene la rama abierta, resuelve un conflicto o investiga un check fallido en la misma conversación. Si trabajas con pull requests apilados, esa parte sigue siendo cosa tuya.

Subagentes. Un agente puede arrancar otro agente en el mismo worktree y en la misma rama, pasarle una tarea, hablarle y pararlo. Cada uno aparece en la barra lateral bajo su workspace. Un workspace admite hasta diez agentes corriendo a la vez.

Ask Bloom. Conversaciones que no pertenecen a ningún workspace, para preguntar sobre tus proyectos.

El puente MCP

Un agente que trabaja dentro de un workspace puede llamar de vuelta a la aplicación por MCP, a través de un shim de stdio que viene dentro del propio paquete de Bloom. Son 36 herramientas: abrir y cerrar paneles, manejar un panel de navegador, ejecutar y leer una terminal, mostrar una imagen en el chat, arrancar y hablar a subagentes, crear y renombrar workspaces, y leer los proyectos y workspaces que Bloom tiene.

Cada herramienta lleva su propia puerta de permisos, y un agente de workspace está acotado a su worktree de forma implícita, de modo que ninguna de sus llamadas lleva un id de workspace. En la práctica eso significa que le puedes pedir "arranca el servidor en una terminal y abre el sitio en un navegador al lado de este chat" y lo hace él.

El mismo puente se puede registrar en un cliente tuyo desde los ajustes, y preguntarle a Bloom por tus proyectos desde una terminal. Si vienes de montar servidores MCP propios, el patrón te va a resultar familiar.

Configuración por repositorio, y el caso Laravel

Un repositorio se configura solo con .bloom/settings.toml, que se apila bajo ~/.bloom/settings.toml y por encima de .bloom/settings.local.toml, ganando el último. Las claves incluyen scripts.setup, scripts.archive, scripts.run, scripts.run_mode, file_include_globs (que por defecto es [".env*"]), git.branch_prefix, git.delete_branch_on_archive, browser.url, models.default y el nivel de razonamiento por defecto de Claude. Cualquier clave terminada en _file apunta a un ejecutable del repositorio en lugar de a un comando en línea.

Cada script recibe estas variables por encima de tu entorno de shell:

La pareja setup y archive es toda la respuesta a la pregunta de qué hace un worktree con su base de datos: setup la crea, archive la borra. Y hay una garantía que evita el desastre clásico, que Bloom no elimina el worktree si el script de archivado no terminó bien. Este es el ejemplo de su documentación para un proyecto Laravel con MySQL:

#!/usr/bin/env bash
set -euo pipefail
 
database="${BLOOM_PROJECT_NAME}_${BLOOM_WORKSPACE_NAME//-/_}"
database="${database:0:64}"
 
cp "$BLOOM_ROOT_PATH/.env" .env
sed -i '' "s/^DB_DATABASE=.*/DB_DATABASE=$database/" .env
sed -i '' "s#^APP_URL=.*#APP_URL=http://localhost:$BLOOM_PORT#" .env
 
mysql -u root -e "CREATE DATABASE IF NOT EXISTS \`$database\`"
 
composer install --quiet
npm ci --silent
php artisan migrate --force
php artisan db:seed --force

Los dos detalles que están comentados en el original y que merecen repetirse: el nombre lleva proyecto y rama, porque una rama llamada main existe en todos tus repositorios y quieres una base de datos por worktree; y se corta a 64 caracteres, porque ahí es donde MySQL deja de aceptar nombres. El script de archivado hace el DROP DATABASE IF EXISTS complementario, y ese IF EXISTS también tiene razón de ser: un archivado que falla bloquea la eliminación del workspace, así que un workspace cuyo setup nunca llegó a crear la base de datos sería uno que nadie podría borrar jamás. El script de archivado dispone de diez minutos.

$BLOOM_PORT es el mismo número antes y después de reiniciar, así que el archivado puede bajar lo que levantó el setup en ese puerto (un docker compose down -v, por ejemplo). Y si tu sitio no vive en ese puerto, porque usas Herd o Valet, escribes la URL real en $BLOOM_URL_FILE, que está dentro del worktree pero cubierto por una regla de ignorado propia de Bloom, así que nunca llega a un commit.

Hay también deep links, para arrancar un workspace desde fuera:

open "bloom://prompt=<urlencoded>&path=<urlencoded repo root>"

Qué cuesta y qué no

Bloom es gratis, es open source con licencia MIT y es postcardware: si lo usas, Spatie te pide una postal de tu ciudad, que acaba en su muro de postales. En su FAQ dicen sin rodeos que seguirá siendo gratis, que no hay nivel de pago planeado y que lo financian con el resto de su trabajo.

Lo que sí cuesta es lo de siempre: correr más agentes consume más de la cuota de tu proveedor. Bloom no cobra nada, pero tu suscripción o tu facturación por API siguen ahí, y cuatro workspaces trabajando en paralelo gastan como cuatro.

Dónde encaja, y dónde no

El propio Freek Van der Herten cuenta el origen en la página: empezó a usar IA en serio para desarrollo en noviembre de 2025, corría sus agentes en Ghostty con un muro de pestañas, probó Conductor y ahí le encajó la idea del worktree. Lo que le faltaba era una aplicación nativa de Mac, y la construyó.

Es honesto respecto a la competencia, y su propia web lista las alternativas: Polyscope, Solo, Amp, Conductor, Orca y Superset. La comparación relevante es corta:

• Frente a la terminal a pelo (Claude Code en pestañas), lo que ganas es el aislamiento por worktree sin gestionarlo tú, y el diff con comentarios que vuelven al agente.
• Frente a Solo, que también es una terminal nativa que orquesta agentes vía MCP, la diferencia es el enfoque: Solo es un workspace de terminal, Bloom es una aplicación de escritorio con inspector de diff y flujo de pull request integrado.
• Frente a todo lo demás, el filtro llega antes que cualquier comparación de funciones: solo hay versión de macOS, no hay planes de Windows ni de Linux, y hace falta macOS 26.

El proyecto es nuevo. El repositorio se creó el 18 de agosto de 2026 y al escribir esto tiene 57 estrellas en GitHub. Va por la 1.9.1, con varias versiones publicadas el mismo día, que es el ritmo de algo que sus autores usan todo el día mientras lo construyen.

Para situarlo entre los demás agentes y los patrones que usan por dentro, está la guía de agentes de IA.

Preguntas frecuentes

Fuentes

• README de spatie/bloom, instalación, requisitos, variables de los scripts, el puente MCP y los deep links
• runbloom.app, página del producto con la FAQ, la guía de setup para Laravel y la lista de alternativas
• Appcast de descargas de Bloom, versión publicada y fecha