---
title: "Bloom, la app de Spatie para correr Claude Code y Codex en paralelo en el Mac"
excerpt: "Bloom es una aplicación nativa de macOS que da a cada tarea su propio git worktree con su rama, corre dentro los CLI de Claude Code o Codex que ya tienes instalados, y te deja revisar el diff y abrir el pull request sin salir de la ventana."
date: "2026-09-10T13:00:00.000Z"
lastModified: "2026-10-11T12:00:00.000Z"
category: "Inteligencia Artificial"
tech_article: true
author:
  name: "angel cruz"
  picture: "/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/runbloom-app-opengraph-image.png"
seo_title: "Spatie Bloom: agentes en paralelo con git worktrees en macOS"
seo_description: "Bloom de Spatie: app nativa de macOS que corre Claude Code y Codex en git worktrees paralelos, con terminal, navegador, MCP y setup script para Laravel."
---

**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](https://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 archivos.

## 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 archivos, 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 archivos 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 archivos 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](/post/clis-orquestar-agentes-ia), 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 pocas dependencias externas: SwiftTerm para los paneles de terminal, Sparkle para las actualizaciones, un motor de Markdown y el cliente de Flare para el reporte de errores, según su `Package.swift`. 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.

```bash
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. No fijo aquí un número de versión a propósito: el proyecto publica varias veces al día, así que cualquiera que escriba queda viejo en un par de días. La lista viva está en [el changelog de Bloom](https://runbloom.app/changelog) y en el propio appcast.

Y lo que tiene que estar en tu `PATH`:

- `claude` ([Claude Code](/post/claude-code-proyecto-laravel)), `codex` o `grok`, al menos uno de los tres. Cada chat elige uno, así que un mismo workspace puede tener conversaciones con varios a la vez.
- `git`.
- `gh`, el CLI de GitHub, solo para las funciones de pull request y de checks. El resto funciona sin él.

Grok es el tercer backend y llegó después que los otros dos, así que hay documentación del proyecto que todavía habla solo de Claude Code y Codex. La selección y el descubrimiento de modelos son comunes a los tres.

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 archivos 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 archivo 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](/post/stacked-pull-requests), 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.

Prompts rápidos. Una biblioteca de prompts que reutilizas, disponible desde cualquier workspace.

Plan y build con Codex. Un chat de Codex separa planificar de implementar, con sus propios permisos. Un plan se guarda, se refina, y se ejecuta en el mismo chat o se le pasa a uno nuevo del mismo workspace.

Volver atrás. Cada turno guarda una instantánea, así que el chat muestra los cambios de archivo tal como estaban en ese momento, incluidos los que hiciste tú desde la terminal. Una conversación de Codex puede rebobinar a un turno grabado y, si lo pides, restaurar también los archivos.

Navegación de código. El visor resuelve definiciones y usos con Cmd+clic, y eso funciona también dentro del diff. En proyectos Laravel corre el LSP de Laravel junto a Intelephense, de modo que Cmd+clic sobre el nombre de una vista abre su archivo Blade.

## La cuota, en la barra de menú

Bloom pregunta una vez por minuto a los CLI de Claude Code y de Codex cuánto queda de tu cuota, y lo pone en la barra de menú del Mac. El menú desglosa cada ventana que reporta el proveedor: el límite de sesión, el semanal, los semanales por modelo, los límites y créditos de Codex y cuándo se reinicia cada uno. Cada fila lleva un medidor coloreado por ritmo y no por nivel, así que una semana que estás gastando demasiado rápido se pone en ámbar antes de agotarse, y dice cuándo lo hará. Preguntar no gasta turno ni dinero.

Al lado está Keep Awake, que mantiene el Mac despierto un rato, o hasta que lo pares, mientras los agentes trabajan. Puede sostenerlo incluso con la tapa cerrada, y para eso usa un ayudante que macOS te pide aprobar una vez; el modo de suspensión se restaura al terminar la sesión, al salir de Bloom y también si Bloom se cae.

## 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. La [referencia del puente](https://github.com/spatie/bloom/blob/main/docs/BRIDGE.md) lista las herramientas, que van creciendo con las versiones: 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](/post/como-crear-un-servidor-mcp), 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:

| Variable | Significado |
| --- | --- |
| `BLOOM_IS_LOCAL` | Siempre `1`. No hay modo nube |
| `BLOOM_WORKSPACE_NAME` | El nombre de la rama con las barras sustituidas por guiones |
| `BLOOM_WORKSPACE_ID` | El id interno del workspace |
| `BLOOM_WORKSPACE_PATH` | El directorio del worktree |
| `BLOOM_PROJECT_NAME` | El nombre de la carpeta del proyecto, limpiado a letras, dígitos y guiones bajos |
| `BLOOM_ROOT_PATH` | El checkout principal |
| `BLOOM_DEFAULT_BRANCH` | La rama por defecto del repositorio |
| `BLOOM_PORT` | El primero de diez puertos asignados a este workspace |
| `BLOOM_URL_FILE` | Un archivo donde escribir la dirección que debe abrir el panel de navegador |

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. La FAQ de runbloom.app trae un ejemplo con Valet y PostgreSQL; este es uno para un proyecto Laravel con MySQL, armado con las mismas variables:

```bash
#!/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
```

Hay dos detalles que conviene explicar: 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:

```bash
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](/post/soloterm-workspace-agentes-ia), Amp, Conductor, Orca y Superset. La comparación relevante es corta:

- Frente a la terminal sola (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: su changelog arranca con la versión 0.1.0 el 21 de agosto de 2026, y el código fuente se publicó en GitHub el 28 de septiembre de 2026. El ritmo de publicación dice más de él que el número de versión que toque hoy: en su primer mes encadenó días con cuatro y cinco releases seguidas, porque sus autores lo usan todo el día mientras lo construyen, con lo bueno y lo malo que eso trae.

Para situarlo entre los demás agentes y los patrones que usan por dentro, está la [guía de agentes de IA](/guia-agentes-ia).

## Preguntas frecuentes

### ¿Qué es Bloom de Spatie?

Una aplicación nativa de macOS que corre agentes de código en git worktrees paralelos. Cada tarea se convierte en un workspace con su propia rama y su propio directorio, con el chat del agente, el diff de lo que cambió, terminales y un navegador en la misma ventana. Es gratis y open source, con licencia MIT.

### ¿Qué agentes soporta Bloom?

Claude Code (`claude`), Codex (`codex`) y Grok, usando el CLI y la sesión que ya tienes en tu Mac. Grok fue el último en sumarse, después de los otros dos. Cursor y OpenCode se detectan en los ajustes pero todavía no están soportados. Bloom no incluye ningún agente propio.

### ¿Bloom funciona en Windows o Linux?

No, y no hay planes. Es una aplicación nativa de macOS y requiere macOS 26 o posterior.

### ¿Cómo se instala Bloom?

Con Homebrew, `brew install --cask spatie/bloom/spatie-bloom`, o descargando la imagen de disco desde runbloom.app. El cask se llama `spatie-bloom` porque el nombre `bloom` en Homebrew corresponde a un gestor de archivos que no tiene relación.

### ¿Correr varios agentes a la vez cuesta más dinero?

Bloom no cobra nada, pero cada agente consume la cuota de tu proveedor. Cuatro workspaces trabajando en paralelo gastan como cuatro agentes: el costo depende de las tareas, los modelos y el plan que uses.

### ¿Cómo configuro un proyecto Laravel en Bloom?

Con un script de setup en `.bloom/setup.sh` registrado en `.bloom/settings.toml` como `setup_file`. Ese script copia el `.env` desde `$BLOOM_ROOT_PATH`, crea una base de datos con nombre derivado de `$BLOOM_PROJECT_NAME` y `$BLOOM_WORKSPACE_NAME`, ajusta `APP_URL` al puerto de `$BLOOM_PORT` o a tu dominio de Herd o Valet, instala dependencias y migra. El `.bloom/archive.sh` complementario borra esa base de datos al archivar el workspace.

### ¿Los agentes pueden controlar la propia aplicación?

Sí, por MCP. Bloom expone sus herramientas a través de un shim que viene dentro de su paquete: abrir y cerrar paneles, manejar el navegador, ejecutar terminales, arrancar subagentes o crear workspaces. Cada herramienta tiene su propia puerta de permisos y un agente de workspace queda acotado a su worktree.

## Fuentes

- [README de `spatie/bloom`](https://github.com/spatie/bloom), instalación, requisitos y backends soportados
- [Referencia del puente MCP](https://github.com/spatie/bloom/blob/main/docs/BRIDGE.md), herramientas y permisos
- [Documentación del archivo de ajustes](https://runbloom.app/docs/settings-file), claves de `.bloom/settings.toml`, variables de los scripts y límite del script de archivado
- [runbloom.app](https://runbloom.app), página del producto con la FAQ, la guía de setup para Laravel y la lista de alternativas
- [Changelog de Bloom](https://runbloom.app/changelog), notas de cada versión: Grok como backend, la barra de menú de límites, Keep Awake, el plan y build de Codex y el límite de diez agentes por workspace
- [Appcast de descargas de Bloom](https://downloads.runbloom.app/appcast.xml), versión publicada y fecha

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/spatie-bloom-agentes-paralelos-mac](https://www.angelcruz.dev/post/spatie-bloom-agentes-paralelos-mac)