Open Source
A long-running service that reads work from GitHub, isolates execution in per-issue workspaces, and runs coding agents to resolve issues autonomously.
What Symphony does
Symphony is an autonomous coding agent orchestration engine. It monitors your GitHub repository for open issues, claims them, spins up isolated per-issue workspaces, and launches coding agents to write code, tests and documentation. The result is a pull request ready for your team to review and merge.
A senior principal controls the architecture and makes every meaningful decision. Symphony handles the mechanical work: scaffolding, wiring, testing and documenting.
Why it exists
Manual issue execution relies on scripts instead of a repeatable daemon workflow. Agent commands run in shared environments with no per-issue workspace boundaries. Workflow prompts and runtime settings are disconnected from the codebase.
Symphony solves all of these problems with a single service that orchestrates agents at scale, with full isolation, policy-as-code, and resilient scheduling.
Platform support
Symphony ships as versioned release bundles with an interactive setup wizard. One binary per platform.
Windows
x64 and ARM64 binaries. Run setup-symphony.cmd to configure your instance.
Linux
x64 and ARM64 binaries. Run setup-symphony.sh to configure your instance.
macOS
x64 and ARM64 binaries. Run setup-symphony.sh to configure your instance.
How it works
Download
Grab the latest release bundle from GitHub. Tags follow semver: v1.2.3 for stable, v1.2.3-rc.1 for pre-release.
Install
Run the interactive installer. It prompts for your GitHub token, repository, base branch and HTTP port, then creates an isolated instance folder.
Configure
Edit WORKFLOW.md in your repo. YAML front matter controls tracker, polling, workspace and agent settings. The prompt template uses Liquid-compatible syntax.
Run
Symphony starts, polls for active issues, claims them, and launches agents in isolated workspaces. A dashboard runs on the configured loopback port.
Review
Agents open pull requests with code, tests and documentation. Your team reviews and merges through your normal GitHub workflow.
Scale
Run multiple isolated instances on one host, each with its own WORKFLOW.md, SQLite database, workspaces and loopback port.
Architecture
| System components | |
|---|---|
| Workflow Loader | Reads and parses WORKFLOW.md for configuration and prompt templates |
| Config Layer | Typed getters, defaults and environment variable indirection for secrets |
| GitHub Tracker | Fetches issues, PRs and milestones from your repository |
| Orchestrator | Polls, dispatches, retries and reconciles issue lifecycle states |
| Workspace Manager | Creates and manages per-issue isolated workspaces with path containment and sanitised names |
| Agent Runner | Builds prompts and launches the Codex CLI with multi-turn support and stall detection |
Technology stack
| .NET Core implementation | |
|---|---|
| Runtime | .NET 8+ / .NET Core |
| HTTP Server | ASP.NET Core Minimal APIs |
| JSON Protocol | System.Text.Json |
| Templates | Fluid (Liquid-compatible) |
| Database | SQLite (instance-local, no external DB required) |
| Installer | Interactive text-mode wizard with Codex CLI preflight checks |
| Packaging | GitHub Release tag bundles per platform |
Isolation and safety
Path containment
Workspace paths must stay inside the configured root. An absolute path prefix check prevents agents from escaping their sandbox.
CWD enforcement
Agent subprocesses launch only in their per-issue workspace directory. Each issue gets its own isolated folder.
Sanitised names
Only alphanumeric characters, dots, hyphens and underscores are allowed in directory names. All others are replaced with underscores.
Lifecycle hooks
after_create, before_run, after_run and before_remove hooks let you run custom logic at each stage of the workspace lifecycle.
Timeout cascade
Three layers of protection: read timeout (5 seconds), turn timeout (1 hour) and stall timeout (5 minutes) to catch stuck sessions.
Resilient recovery
No persistent database required. On restart, Symphony cleans up terminal workspaces, polls for active issues and re-dispatches eligible work.
Model-agnostic execution
Symphony uses Codex CLI as its execution engine. Codex CLI supports virtually any LLM provider through OpenAI-compatible endpoints, so Symphony is never locked into a single AI vendor. As new, more capable models emerge, Symphony can switch seamlessly.
OpenAI / GPT
GPT-5.4, o3, o4-mini
Anthropic / Claude
Sonnet 4.6, Opus 4.6
Google / Gemini
Gemini 3.1 Pro, Flash
Open Source
Llama 4, DeepSeek V3.2, Qwen 3.5
Monitoring and API
| REST API endpoints | |
|---|---|
| GET / | Human-readable dashboard |
| GET /api/v1/state | Full system snapshot |
| GET /api/v1/:id | Issue-specific debug information |
| POST /api/v1/refresh | Trigger an immediate poll cycle |
Runtime metrics include token accounting (input, output, total), session tracking with turn counts, retry queue with backoff timers, and the latest rate-limit snapshot from the agent event stream.
Get started
Star the repo, download a release bundle, run the interactive installer, and Symphony starts resolving your GitHub issues.
Download on GitHub Back to Symphony