← Back to feed

OpenAI formally announced Symphony on April 27, two months after its GitHub repository first appeared. The project is a language-agnostic specification — and an Elixir reference implementation — for a long-running daemon that watches a Linear issue board and dispatches a Codex agent session for each issue it picks up.

The idea is a level of abstraction above “run this agent on this task.” Symphony’s unit of work is the issue, not the prompt. An engineer marks a ticket as ready; Symphony picks it up, provisions an isolated workspace, builds a prompt from the issue description plus the repo’s WORKFLOW.md policy file, launches Codex, and streams back CI status, PR review feedback, and a walkthrough on completion. The engineer reviews and approves the PR. At no point does anyone supervise the agent session itself.

The Design Decisions That Matter

Per-issue workspace isolation. Every issue gets its own directory. Agent commands can’t bleed across sessions. This is the safety boundary that makes unattended operation tractable without a full sandbox.

WORKFLOW.md as the contract. The workflow policy lives in the repository, version-controlled with the code. Teams change agent behavior by committing a file, not by reconfiguring an external service. This is the same pattern Codex uses for its harness — Symphony extends it to the orchestration layer.

No persistent database required. Symphony’s orchestrator state is in-memory and restartable. This keeps the deployment surface minimal: a single process, filesystem access, Linear API credentials, and a Codex app-server binary.

Spec-first, not product-first. OpenAI has said explicitly it won’t maintain Symphony as a standalone product. The spec is language-neutral — the README instructs developers to ask their favorite coding agent to implement it in any language they prefer. OpenAI wrote the Elixir version by asking Codex to do it; Go, TypeScript, Python, Rust, and Java variants were generated to surface spec ambiguities.

Numbers

• 18,615 GitHub stars as of April 29
• 1,550 forks
• Published April 27, 2026 on openai.com/index/open-source-codex-orchestration-symphony/
• License: Apache 2.0
• Reference implementation: Elixir (95.4% of code), with Python tooling
• Last commit: April 27

The Broader Context

Symphony is a spec for how coding agents should be managed at the project level — not how they reason, not how they generate code, but how work gets assigned, isolated, and delivered. The fact that OpenAI is publishing this as an open standard rather than a proprietary product is a deliberate move: they want Symphony-compatible tooling to proliferate around Codex, not to own the orchestration layer themselves.

The immediate comparison is AWS AgentCore, which ships a persistent filesystem and execution environment but positions itself as infrastructure, not workflow. Symphony is opinionated about workflow — it wants Linear, per-issue isolation, and repo-owned policy — while staying silent on the execution environment. The two could coexist.

For teams already running Codex at scale, Symphony provides the scaffolding that most of them have been building internally anyway: a way to stop babysitting agent sessions one by one and manage work queues instead.