MCP server de headlesscode
Commit 2 nov 2026Un entorno de ejecución para agentes de programación que realiza tareas, gestiona trabajadores en paralelo mediante Git worktrees y permite la mejora recursiva mediante sesiones en entornos aislados.
También conocido como Capsize-Games/headlesscode
- Stars
- 2
- Herramientas
- —
- Descargas, 30 días
- —
- Última versión
- —
- Último commit
- 2 nov 2026
- Licencia
- Apache-2.0
¿Qué es headlesscode MCP?
headlesscode es un MCP server. Un entorno de ejecución para agentes de programación que realiza tareas, gestiona trabajadores en paralelo mediante Git worktrees y permite la mejora recursiva mediante sesiones en entornos aislados.
Resumen generado a partir del README del proyecto
Acerca del MCP server de headlesscode
headlesscode permite a los desarrolladores automatizar tareas complecas de ingeniería de software mediante un entorno de ejecución para agentes de programación. Funciona como una interfaz de línea de comandos y un sistema basado en HTTP que puede ejecutar tareas en repositorios individuales, gestionar trabajadores en paralelo usando Git worktrees o automatizar la recepción de tareas vigilando las etiquetas de GitHub. El sistema admite la mejora recursiva al permitir que un agente inspeccione y repare su propio código o proyectos objetivo mediante bucles de evaluación independientes.
Los usuarios pueden ejecutar sesiones localmente o dentro de entornos aislados utilizando el proveedor NVIDIA OpenShell, que utiliza clones de Git desechables para aislar la ejecución. Para funcionar, el entorno requiere un entorno Node.js y una clave de API de OpenRouter o de la Meta Model API. También puede conectarse a MCP servers locales de tipo stdio o HTTP definidos en un archivo de configuración de usuario. Aunque ofrece controles de seguridad como presupuestos de recursos y configuraciones de permisos, por defecto ejecuta comandos de shell con los privilegios existentes del usuario.
Qué puedes hacer con él
- 1Resolución automatizada de incidenciasUn desarrollador puede dividir los issues de GitHub en diferentes Git worktrees para ejecutar trabajadores en paralelo que monitoreen y revisen los cambios.
- 2Ejecución de código en entornos aisladosPuedes ejecutar sesiones de trabajadores y de revisión en clones desechables para asegurar que el sistema host permanezca aislado.
- 3Bucles de mejora recursivaEl entorno puede utilizarse para ejecutar experimentos limitados donde el agente intenta mejorar su propio código.
- 4Sesiones de programación interactivasLos desarrolladores pueden iniciar un chat de terminal para mantener una conversación interactiva con el agente sobre un espacio de trabajo específico.
Escrito a partir del README del proyecto. Cada caso de uso se verifica con una cita del mismo.
Configuración
GH_TOKENHEADLESSCODE_LLM_PROVIDERHEADLESSCODE_MUSE_API_KEYHEADLESSCODE_OPENROUTER_API_KEYHEADLESSCODE_OPENSHELL_POLICY
| Nombre | Descripción | Tipo |
|---|---|---|
| GH_TOKEN | — | |
| HEADLESSCODE_LLM_PROVIDER | — | |
| HEADLESSCODE_MUSE_API_KEY | — | |
| HEADLESSCODE_OPENROUTER_API_KEY | — | |
| HEADLESSCODE_OPENSHELL_POLICY | — |
Verificaciones automáticas
Ejecutado 14 nov 2026Informe completo →Aún no verificado. Un servidor necesita una puntuación de 80, ningún hallazgo grave y suficientes datos para que podamos revisarlo. Cómo funcionan las verificaciones · Qué corregir para obtener más puntos
- Repositorio de origen vinculado y accesiblecapsize-games/headlesscode is public and reachablegithub.com/capsize-games/headlesscode ↗Aprobado
- El paquete indica este repositorio como su origenNo verificado
- Procedencia de la compilación (atestación de Sigstore)No verificado
- Licencia de código abierto (OSI)Apache-2.0spdx.org/licenses/Apache-2.0.html ↗Aprobado
- Commit o lanzamiento en el último añoLast commit or release 2026-11-02github.com/capsize-games/headlesscode ↗Aprobado
- OpenSSF ScorecardNo verificado
- El nombre del paquete no es similar a un paquete popularNo verificado
- No hay avisos críticos en el paquete ni en sus dependenciasNo verificado
- Sin instrucciones ocultas para el modelo0 tool descriptions and the README read; no override phrases, credential paths or hidden charactersAprobado
- Las herramientas destructivas están etiquetadasNo verificado
- El endpoint remoto responde al handshake de MCPNo verificado
README
Ver en GitHubheadlesscode
HeadlessCode is a coding-agent harness with a CLI, HTTP interfaces, and recursive self-improvement (RSI). Run one task directly, launch parallel workers in Git worktrees, or use the NVIDIA OpenShell provider for sandboxed sessions. The bounded RSI harness can inspect and improve a target project, including HeadlessCode itself, with independent evaluation of candidate changes.
Security controls
HeadlessCode's controls map to the seven principles in Satya Nadella's Models as Insider Risks in the Super Intelligence Era.
| Principle | HeadlessCode implementation |
|---|---|
| Model diversity | Operators assign models by mode and RSI role, including review and adversarial roles. Programmatic gates determine candidate eligibility. See model assignment and RSI roles. |
| Observe everything | Evidence-required sessions wait for an external collector's authenticated acknowledgement before model calls and tool actions. The collector signs a hash-linked journal and session head; an offline verifier produces a readable history and distinguishes worker reports from supervisor observations. See evidence journal. |
| Verifiability | CI runs typechecking, the full automated suite, and mock workflows. Tests exercise missing evidence acknowledgements, tampering, replay, stop races, and cleanup failures. RSI applies regression and frozen proof gates; configured hidden verification checks bounded function cases against supervisor-held answers. See CI and hidden verification. |
| Independent controls | Operators configure command and file permissions, resource and inference budgets, and a contained profile that pins the OpenShell policy, image, gateway, evidence key, and emergency controller. Launch preflight checks those identities and the sandbox's effective policy. See permissions and security profiles. |
| Independent auditability | The external collector owns evidence signing keys and storage. The hidden verifier keeps expected answers and signing keys in the supervisor, binds reports to the candidate source, session, job, limits, and one-time nonce, and compares outputs outside the candidate guest. See evidence boundaries and hidden verification. |
| Containment | OpenShell runs sessions in disposable independent clones. The host emergency controller can pause or stop active work, abort model calls, terminate scoped command groups, and delete sandboxes. Result import requires confirmed sandbox deletion. See emergency controls and OpenShell lifecycle. |
| Incident disclosure | GitHub private vulnerability reporting provides confidential intake. The incident procedure covers containment, evidence preservation, fixes, affected-user notification, coordinated advisories, and review of failed controls and runtime configuration changes. See incident response, report a vulnerability, and advisories. |
| Use it for | What it does |
|---|---|
| One repository task | Reads project modes and instructions, edits files, runs commands, and reports a result. |
| Parallel issue work | Splits GitHub issues into Git worktrees, runs workers, monitors completion, and reviews changes. |
| Intake automation | Watches a GitHub label and starts bounded batches of work. |
| OpenShell sessions | Runs worker and review sessions in disposable clones, then validates and imports results after sandbox deletion. |
| Harness experiments | Runs a bounded recursive self-improvement loop against an external evaluator. |
| Project work with harness repair | A host work loop runs tasks, independently checks observed harness problems, and retries with verified repairs. |
Security
Default-allow arbitrary command execution. By default,
headlesscoderuns shell commands with the invoking user's privileges. It can read and modify files, including credentials such as~/.sshand~/.aws, without approval prompts. Use it only with trusted tasks and isolate it with a container, VM, or dedicated user when untrusted content is involved. The optional permissions layer is defense in depth, not a security boundary. SeeSECURITY.md.
OpenShell runs each session in a disposable Git clone mounted at /workspace;
the host worktree and harness control files are not mounted. After the sandbox
is deleted, HeadlessCode validates a Git bundle and imports the result into the
host worktree. The gateway must support Docker bind mounts and must see the
configured scratch root at the same absolute path as the host. See the
OpenShell guide for setup and security
details. This integration does not configure NVIDIA Sentry or hardware
monitoring.
Quick start
Requires Node.js 22.19 or newer. Install globally or run with npx:
npm install -g headlesscode
# or
npx headlesscode --task "Fix the bug in src/index.ts" --workspace /path/to/repo
For a real model call, set the OpenRouter key. --dry-run does not need a key.
| Variable | Required | Purpose |
|---|---|---|
HEADLESSCODE_OPENROUTER_API_KEY |
For OpenRouter calls | OpenRouter API key. |
OPENROUTER_MODEL |
No | Default model; meta/muse-spark-1.3-contributor. --model overrides it. |
OPENROUTER_HTTP_REFERER |
No | OpenRouter application referer header. |
OPENROUTER_APP_TITLE |
No | OpenRouter application title header. |
HEADLESSCODE_WORKSPACE_ROOT |
No | Default workspace; otherwise the current directory. |
export HEADLESSCODE_OPENROUTER_API_KEY=sk-or-...
headlesscode --task "Fix the bug in src/index.ts" --workspace /path/to/repo
The default model is Muse Spark 1.3 Contributor through OpenRouter. OpenRouter lists it at $0.10/M input tokens, $0.20/M output tokens, and $0.002/M cached
input tokens. OpenRouter notes that prompts and outputs sent to this Contributor
model may be used to improve Meta's products. Use OPENROUTER_MODEL or
--model to select another OpenRouter model.
Using Meta's Model API (Muse) instead
Set HEADLESSCODE_LLM_PROVIDER=muse to run sessions against Meta's Model
API (https://api.meta.ai/v1, OpenAI-compatible) with the Muse Spark
family instead of OpenRouter. Get a key from the
Model API dashboard. The default model is
muse-spark-1.3 (1M context); --model and mode-models.json entries
work the same as on the OpenRouter path. orchestrate preflight,
per-session cost budgets, and the local Ollama backend all apply unchanged.
| Variable | Required | Purpose |
|---|---|---|
HEADLESSCODE_LLM_PROVIDER |
No | "openrouter" (default) or "muse". |
HEADLESSCODE_MUSE_API_KEY |
For Muse calls | Meta Model API key (MODEL_API_KEY also works). |
HEADLESSCODE_MUSE_MODEL |
No | Default model; muse-spark-1.3. Shadows OPENROUTER_MODEL. |
HEADLESSCODE_MUSE_BASE_URL |
No | API base URL; https://api.meta.ai/v1. |
export HEADLESSCODE_LLM_PROVIDER=muse
export HEADLESSCODE_MUSE_API_KEY='LLM|...'
headlesscode --task "Fix the bug in src/index.ts" --workspace /path/to/repo
Notes: the -contributor model variants (muse-spark-1.3-contributor,
muse-spark-1.2-contributor) use the Contributor pricing tier
and permit Meta to train on the traffic. Select them explicitly when using the
direct Meta API; its default is the Standard model. Vision
captioning (describe_image, screenshots) and OpenShell sandboxed
execution still use OpenRouter regardless of this setting.
For a source checkout:
git clone https://github.com/Capsize-Games/headlesscode.git
cd headlesscode
npm install
node bin/headlesscode.mjs --task "Fix the bug in src/index.ts" --workspace /path/to/repo
To install a headlesscode wrapper on your PATH, run scripts/install-cli.sh.
It writes to ~/.local/bin by default (override with HEADLESSCODE_BIN_DIR)
and runs this checkout's local tsx. Re-run it if you move the checkout.
Terminal chat, skills, and saved sessions
headlesscode chat starts an interactive conversation. Each turn uses the
existing runner and saves its messages for resume or fork. /help lists the
session, model, mode, skill, and import controls.
headlesscode chat --workspace /path/to/repo
headlesscode skills import /path/to/my-skill
headlesscode sessions import --from codex --file /path/to/rollout.jsonl --workspace /path/to/repo
headlesscode chat --resume <session-id> --workspace /path/to/repo
Skills use SKILL.md instructions and captured text references. Session
imports support Claude Code, Codex, and Muse history, with provenance and
warnings. Imported tool calls stay historical context. See terminal chat,
skills, and sessions for formats,
discovery, and security behavior.
Coding sessions can also create and use reusable skills, Node tools, and local
stdio MCP servers through extension_manage and extension_call. Each call
pins an immutable revision and uses the session's existing permissions. The
fixed interfaces keep extension contents out of the system prompt and tool
catalog. See workspace extensions for the bundle format
and runtime limits.
Check project instructions without calling a model
--dry-run builds the system prompt and validates project configuration. It
prints the prompt and a summary of loaded modes, tools, and prompt size. A
successful exit means prompt building and mode/rules loading succeeded.
headlesscode --dry-run --mode code --workspace /path/to/repo
Project .roomodes, .roo/rules-<slug>/, and AGENTS.md instructions are
loaded by the prompt builder when applicable. The selected mode controls which
tools are exposed. See Architecture for the relevant code.
Local MCP services
HeadlessCode can connect to user-configured stdio and Streamable HTTP MCP
servers. It reads ~/.config/capsize-agent/mcp.json by default; set
HEADLESSCODE_MCP_CONFIG to use another trusted, user-owned manifest. It does
not execute MCP commands from a workspace .mcp.json. Connected server tools
are exposed to modes that allow the mcp tool group. Offline servers are
reported in the session prompt/log while other servers continue to work.
The MCP client does not add an approval layer around server tools. Treat each configured server's capabilities as available to the agent, and use HeadlessCode only for trusted tasks. See MCP servers for configuration, limits, and local setup details.
OpenShell
Build the worker image and import the OpenRouter provider profile once. Configure a Docker-backed OpenShell gateway with driver-config and bind-mount support; keep that gateway restricted to trusted operators.
# Run these commands from a HeadlessCode source checkout.
docker build -f docker/OpenShell.Dockerfile -t headlesscode-openshell:local .
openshell profile import -f shared/openshell/headlesscode-openrouter.yaml
export HEADLESSCODE_OPENROUTER_API_KEY=sk-or-...
export HEADLESSCODE_OPENSHELL_POLICY="$PWD/shared/openshell/headlesscode-policy.yaml"
headlesscode orchestrate --repo /path/to/repo --issue 42 \
--execution-provider openshell
Each worker gets an independent clone and a temporary result directory. Neither
bind source is the host worktree. After the sandbox is deleted, HeadlessCode
imports a verified Git bundle into the host branch. The default scratch root is
~/.local/share/headlesscode/openshell-sessions; create it before starting the
gateway and bind-mount it into the gateway container at the same absolute path.
If you choose another root, set HEADLESSCODE_OPENSHELL_SCRATCH_ROOT and mount
that host directory into the gateway container at the same path. Project data and shared instructions
are copied into the scratch tree and mounted separately. The writable scratch
checkpoint store supports checkpoints during a session and is discarded at
teardown. Opt-in memory uses a scratch snapshot and merges validated JSONL
records after sandbox deletion. No OpenRouter key is passed as a normal sandbox
environment argument; OpenShell injects the imported provider credential.
headlesscode watch accepts the same --execution-provider openshell option.
OpenShell applies to worker, plan-first, continuation, reviewer, QA, and rework
sessions. The one-off headlesscode openshell-session command runs a single
task and keeps its host worktree for review. Set up a gateway callback address
that the sandbox's Docker bridge can reach; keep the client endpoint loopback
only when possible. Read the OpenShell guide
before adapting the sample gateway or filesystem policy.
| Setting | Default | Meaning |
|---|---|---|
--execution-provider |
local |
orchestrate/watch runtime: local or openshell. Also settable with HEADLESSCODE_EXECUTION_PROVIDER. |
HEADLESSCODE_OPENSHELL_POLICY |
No default | Base OpenShell policy YAML; required for OpenShell sessions. |
HEADLESSCODE_OPENSHELL_IMAGE |
headlesscode-openshell:local |
Sandbox image. |
HEADLESSCODE_OPENSHELL_PROVIDERS |
headlesscode-openrouter |
Comma-separated credential profile names. |
HEADLESSCODE_OPENSHELL_CPU / HEADLESSCODE_OPENSHELL_MEMORY |
2 / 4Gi |
Per-sandbox resource requests. |
HEADLESSCODE_OPENSHELL_NAME_PREFIX |
hcls |
Prefix for deterministic sandbox names. |
HEADLESSCODE_OPENSHELL_SCRATCH_ROOT |
~/.local/share/headlesscode/openshell-sessions |
Host scratch directory that the gateway container must see at the same path. |
The headlesscode openshell-session command provides a single-session live
entry point; run headlesscode openshell-session --help for options.
Parallel work and GitHub intake
orchestrate runs a parallel round from GitHub issue numbers or a JSON file.
It splits work, creates a worktree per group, starts workers, watches for
completion, and reviews results. QA and deployment approval are optional.
headlesscode orchestrate --repo /path/to/repo --issue 42 --issue 43 --qa
headlesscode orchestrate status --repo /path/to/repo --wait --timeout-ms 7200000
watch polls GitHub for issues with a chosen label and starts bounded batches.
It requires GH_TOKEN or GITHUB_TOKEN; it performs intake only. Use a later
orchestrate run to monitor, review, QA, or deploy a batch.
GH_TOKEN=... headlesscode watch \
--owner my-org --repo /path/to/repo --label needs-agent --run-once
| Command | Important options | Behavior and limits |
|---|---|---|
headlesscode orchestrate --repo <path> |
Repeat --issue <n> or use --issues-json <file>; `--execution-provider local |
openshell, --qa, --deploy, --no-review, --dry-run, --max-iterations , --max-rework-cycles , --max-continuations ` |
headlesscode orchestrate status --repo <path> |
--wait, --timeout-ms <n>, --json |
Reads durable round state; --wait blocks until terminal state or timeout. |
headlesscode orchestrate stop --repo <path> |
Repeat --group <name> |
Stops selected groups' worker process trees. |
headlesscode watch --owner <o> --repo <path> --label <name> |
`--execution-provider local | openshell, --run-once, --dry-run, --max-per-sweep , --max-concurrent-sessions , --retry-failed` |
Both orchestration and watcher enforce a shared concurrency cap, defaulting to
3 (HEADLESSCODE_MAX_CONCURRENT_SESSIONS). Orchestration aborts when the cap
is full; the watcher leaves excess issues pending. The watcher records
idempotency state under <repo>/.worktrees/.watcher-state.json by default.
Use --help on a command for its complete options. Detailed guides:
orchestration,
issue watcher,
QA implementation, and
deployment gate.
Project registration and search
Registering a project detects its stack, ensures .gitignore excludes
.headlesscode/, and builds a code-search index and codemap. Indexing calls an
embedding API and can incur charges unless skipped or configured for Ollama.
headlesscode init --workspace ~/Projects/your-project
headlesscode init --workspace ~/Projects/your-project --skip-index
See headlesscode init --help for --skip-codemap and embedding-backend
options. The CLI also provides index, codemap, project-store, GitHub App,
and decision-proxy commands; run headlesscode --help for the command list
and each subcommand's --help for complete usage.
Recursive self-improvement
headlesscode improve --dry-run resolves the base commit and prints planned
candidate worktrees. A real run requires PostgreSQL, a shared S3-compatible
artifact store, and at least one registered headlesscode rsi-worker. The
coordinator queues sanitized mutation snapshots and visible evaluation jobs;
workers run each in a fresh OpenShell guest. Fitness, paired baseline
comparison, archives, and selection stay in the coordinator. Hidden evaluation
remains disabled. A 2026-09-29 bounded run used two workers on the same local
OpenShell gateway; both candidate evaluation jobs were leased concurrently.
The run used a temporary clamp.js fixture and does not establish general
headlesscode improvement or multi-gateway operation. An earlier bounded run
passed visible checks but made no source change and was rejected.
npx tsx src/cli.ts improve --repo . --dry-run
npx tsx src/cli.ts improve --repo . --population 2 --generations 1
Before starting workers, build the standard and RSI guest images on each OpenShell gateway host that will run RSI jobs. Build the larger training image only on gateways whose workers will accept model-training or paired model-evaluation jobs:
docker build -f docker/OpenShell.Dockerfile -t headlesscode-openshell:local .
docker build -f docker/OpenShell-RSI.Dockerfile -t headlesscode-openshell-rsi:local .
docker build -f docker/OpenShell-RSI-Training.Dockerfile -t headlesscode-openshell-rsi-training:local .
The RSI Dockerfile extends headlesscode-openshell:local and removes the RSI
source, test files, and hidden evaluation suite from the guest image. See the RSI design
for worker and queue configuration.
The queue stores job state, worker registrations, leases, retries, and admission policy in PostgreSQL; artifact bytes remain in object storage. Local integration tests used 12 simulated workers and 100 queued jobs, including a 20 MiB artifact. Each worker process currently runs one guest at a time and must be configured with a unique worker ID and OpenShell gateway ID. The two-worker run observed 4.008 seconds of concurrent evaluation leases on one gateway. A local PostgreSQL/ RustFS test drained the remaining 96 jobs with 12 simulated workers in 446 ms (215.2 jobs/s), after the initial four jobs were claimed and completed to verify admission limits; claims still serialize on a queue-policy row, and neither result qualifies a multi-host deployment. Remaining work is:
| Issue | Work |
|---|---|
| #3 | OpenShell candidate isolation is implemented; live multi-gateway qualification remains. |
| #4 | Content-addressed artifacts are implemented; signed evaluator provenance and hidden evaluation remain. |
| #5 | PostgreSQL queue, leases, retries, admission, and configured workers are implemented; live fleet qualification remains. |
| #6 | Bounded adaptive independent search supports an initial population plus one evidence-driven follow-up; repeated stages remain out of scope. |
| #7 | Fixture-backed curriculum replay and explicit promotion are implemented; wording-to-capability measurement remains unproven. |
| #8 | Adversarial review and bounded OpenShell break tests are implemented; live provider-backed review is unvalidated. |
| #9 | An OpenShell QLoRA prototype is covered by mocked job tests; the supplied GGUF is rejected before enqueue, and no live training is validated. |
See the RSI design and run progress.
Preguntas sobre headlesscode MCP
¿Cuál es la postura de seguridad predeterminada de headlesscode?
Por defecto, permite la ejecución de comandos arbitrarios con los privilegios del usuario que lo invoca, lo que incluye la lectura y modificación de archivos sensibles como credenciales de SSH o AWS.
¿Cómo puedo ejecutar headlesscode sin una clave de API de LLM?
Puedes usar el flag --dry-run, que construye el system prompt y valida la configuración sin realizar llamadas al modelo.
¿Es compatible headlesscode con MCP servers?
Sí, puede conectarse a MCP servers de tipo stdio y streamable HTTP configurados por el usuario a través de un archivo de configuración.
¿Para qué se utiliza OpenShell?
OpenShell ejecuta las sesiones de trabajadores y de revisión en clones de Git desechables y aislados para proporcionar contención.