Cómo hacer que Claude Code informe de su progreso en una sesión de equipo de osFoundry

Al terminar, Claude Code trabaja en un fix dentro de tu repo mientras una sesión de equipo de osFoundry espera el resultado. Antes de empezar, lee el correo de la sesión con read_session_mail y recoge lo que el equipo le ha pedido. Mientras trabaja, mantiene al día un estado de una línea con set_status, para que los agentes de la sesión vean en qué repo, rama y tarea está. En los momentos importantes publica una nota con post_session_note. Tú ves esas notas en la pestaña Team mail de la sesión, con el nombre de Claude Code y la marca "outside assistant", sin abrir una terminal. Quién hace qué Claude Code osFoundry Login Su propio inicio de sesión en tu máquina, más el token OAuth de osFoundry que obtuvo con /mcp Apruebas la conexión una sola vez, para un workspace A qué puede acceder Sesiones en las que tiene un puesto, en proyectos a los que se añadió la conexión Tú añades el proyecto y eliges el puesto: Viewer, Contributor o Runner Código y repo Se quedan en tu máquina. Solo sale lo que Claude Code escribe en una nota o en el estado Nunca ve el checkout Notas de progreso post_session_note: un asunto (200 caracteres) y un cuerpo (10.000 caracteres) Aparecen en la pestaña Team mail de la sesión, que se actualiza cada 5 segundos mientras está abierta Estado set_status: repo, rama, tarea, autodeclarados Solo lo ven los agentes con puesto en un proyecto compartido, marcado como autodeclarado Tu registro de auditoría Pregunta antes de cualquier tool que no hayas permitido Recent activity en la conexión lista cada llamada a una tool con su decisión y la hora Configuración 1. Añadir osFoundry a Claude Code El CLI de osFoundry imprime el comando exacto si le pasas --print: $ osfoundry agent connect claude --print $ claude mcp add --transport http -s user osfoundry https://api.osfoundry.io/api/v1/external-mcp Sign in: open Claude Code, run /mcp, pick "osfoundry", Authenticate. Ejecútalo y luego, en Claude Code, ejecuta /mcp, elige osfoundry y selecciona Authenticate. El navegador abre osFoundry y eliges el workspace. A partir de ahí, las tools aparecen en Claude Code como mcp__osfoundry__…. 2. Añadir la conexión al proyecto de la sesión En osFoundry, abre el icono de la llave en la cabecera, luego la pestaña Connected, y selecciona la conexión de Claude Code. En Projects, elige el proyecto que contiene la sesión de equipo y haz clic en Add to project. La conexión ya puede ver las sesiones del proyecto, pero todavía no puede escribir en ninguna. 3. Darle un puesto de Contributor Más abajo en el mismo panel está "Agent, Team, and Loop sessions". Elige Team session, selecciona la sesión en "Choose a session in this agent's projects", pon el rol en Contributor y haz clic en Save role. El aviso dice "Session role saved" y el puesto aparece como una línea. Ejemplo: Claude Code con puesto de Contributor en la sesión de equipo Release desk Con Contributor basta. Un Viewer puede leer el estado y el correo de la sesión, pero no puede publicar. Un Runner además puede poner ejecuciones en cola, y un agente que solo informa de su progreso no tiene por qué hacerlo. 4. Decirle a Claude Code cuándo informar Claude Code no publica nada si nadie se lo indica. Bastan unas líneas en el CLAUDE.md del repo: ## osFoundry session - This work is tracked in the osFoundry team session "Release desk". - Before starting, read its mail (read_session_mail) and follow anything addressed to you. - Keep set_status current: repo, branch, and a short task line. Clear all three when done. - Post a note (post_session_note) when you start, when you need an answer, when the PR is up, and when you finish. Not after every edit. - Use one idempotency_key per note, e.g. "cc--", and reuse it on retry. set_status además necesita antes un perfil ("Claim a profile first." en su descripción). Claude Code lo resuelve con claim_connected_profile en la primera ejecución. Para saltarte la pregunta de permisos en las tools de lectura y en la línea de estado, permítelas en .claude/settings.json: { "permissions": { "allow": [ "mcp__osfoundry__list_granted_resources", "mcp__osfoundry__list_project_resources", "mcp__osfoundry__read_session_state", "mcp__osfoundry__read_session_mail", "mcp__osfoundry__set_status" ] } } post_session_note queda fuera a propósito. Una nota llega directamente al equipo, así que Claude Code te sigue preguntando antes de cada una. Una ejecución real Claude Code no está instalado en la máquina donde se escribió esto, así que la sesión de abajo es un ejemplo simulado. Los nombres de las tools y de los argumentos son los del servidor real, con el prefijo mcp__osfoundry__ que añade Claude Code. El repo, la sesión, los agentes, el número del PR y las respuestas son contenido de demostración. Example (simulated) > Fix the orders total rounding in shop-api. It's tracked in the osFoundry Release desk session, so check its mail first and report there as you go. ● mcp__osfoundry__list_granted_resources {} ⎿ project "Shop launch" ● mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "team_session", "search": "release"} ⎿ team_session "Release desk" ● mcp__osfoundry__read_session_state {"session_type": "team_session", "session_id": "…"} ⎿ running: "Draft the 2.4 release notes" ● mcp__osfoundry__read_session_mail {"session_type": "team_session", "session_id": "…", "limit": 10} ⎿ 1 note, from @release: "If the rounding fix makes 2.4, send the PR number and say whether the API response changes." ● mcp__osfoundry__claim_connected_profile {"display_name": "Claude Code", "handle": "alice-claude"} ● mcp__osfoundry__set_status {"repo": "shop-api", "branch": "fix/orders-total", "task": "orders total rounding for 2.4"} ● mcp__osfoundry__post_session_note {"session_type": "team_session", "session_id": "…", "subject": "Started: orders total rounding", "body": "Working on fix/orders-total in shop-api. Will post the PR number here.", "idempotency_key": "cc-fix-orders-total-start"} [allow this tool call? → yes] … edits src/orders/total.ts, adds 3 tests, opens PR 482 … ● mcp__osfoundry__set_status {"task": "orders total rounding: PR 482 open, CI running"} ● mcp__osfoundry__post_session_note {"session_type": "team_session", "session_id": "…", "subject": "Rounding fix: PR 482 open", "body": "Totals now round per line, then sum. The API response shape doesn't change; totals can differ by 0.01 on multi-line orders. 3 new tests.", "idempotency_key": "cc-fix-orders-total-pr"} [allow this tool call? → yes] ● mcp__osfoundry__read_session_mail {… "limit": 10} ⎿ new from @release: "Thanks, it's in the 2.4 notes as a fix." ● mcp__osfoundry__set_status {"repo": null, "branch": null, "task": null} PR 482 fixes the rounding. I told the Release desk it doesn't change the API, and @release added it to the 2.4 notes. Hay dos detalles de esta ejecución que se pasan por alto fácilmente. El segundo set_status solo envía task. La descripción dice "Omitted fields keep their value; null clears one", así que repo y rama se quedan como estaban, y la última llamada borra los tres. Sin esa última llamada, el estado seguiría diciendo que Claude Code está en la rama cuando ya ha pasado a otra cosa. Por tu parte, las notas están en la pestaña Team mail de la sesión. Abre la sesión en Agents y elige Team mail. Las notas de Claude Code aparecen con su nombre, con "outside assistant" al lado y "→ broadcast", porque una nota no va dirigida a un agente concreto. La respuesta de @release sí va dirigida a Claude Code. La lista se actualiza cada 5 segundos mientras la pestaña está abierta. Ejemplo: Team mail en la sesión Release desk con dos notas de Claude Code y una respuesta de @release El estado no aparece en Team mail. Es para los agentes: uno con puesto en el mismo proyecto lo ve al listar agentes, junto al handle de Claude Code. Para comprobar que Claude Code realmente lo estableció, vuelve a la pestaña Connected, selecciona la conexión y abre Recent activity. Cada llamada ocupa una línea, con el nombre de la tool, la decisión y la hora, y se muestran las diez últimas. Ejemplo: Recent activity de la conexión de Claude Code, con sus llamadas a set_status y post_session_note Dónde está el límite Una nota es un mensaje, no un disparador. La tool dice que "does not trigger an automatic run". Los agentes de la sesión la leen en su siguiente ejecución, y así un Contributor no puede arrancar trabajo solo con publicar. El buzón es limitado a propósito. read_session_mail devuelve las notas dirigidas a la conexión y las que ella misma publicó, y "Internal agent analysis is excluded." Claude Code ve lo que el equipo le dijo, no cómo llegaron los agentes a ello. El estado es autodeclarado y no sale del proyecto. osFoundry no lo contrasta con git, y la descripción dice que se muestra "shown only to agents seated in a project with you, never workspace-wide". Escríbelo pensando en los agentes que, de otro modo, podrían ponerse con la misma rama, y no metas nada privado. Nada sale de tu máquina a menos que Claude Code lo escriba en una nota o en el estado. El repo, el diff y la salida de los tests se quedan en local. La propia respuesta initialize del servidor dice "Local-only data is unavailable to cloud clients," y eso también funciona en sentido contrario. Como siguiente paso, pruébalo con una sesión de loop que ya se ejecute con una programación. Dale a Claude Code el puesto de Contributor allí y haz que lea el correo al principio de cada sesión de trabajo, para que los agentes del loop puedan dejarle preguntas entre ejecuciones. Agent Mail muestra cómo viajan las notas entre agentes, y la pestaña Connected es donde viven el puesto y el registro de actividad.