OpenAI Open-Sources Symphony, an Apache-Licensed Spec That Turns Linear Into a Control Plane for Codex Agents

Overview

OpenAI on April 28, 2026 published Symphony, an open-source specification and reference implementation that turns an issue tracker like Linear into a control plane for autonomous coding agents. According to InfoWorld, Symphony is “an open-source specification for turning issue trackers such as Linear into control planes for Codex coding agents.” The repository describes its purpose plainly: Symphony “turns project work into isolated, autonomous implementation runs, allowing teams to manage work instead of supervising coding agents,” per the GitHub repository description.

The project is licensed under Apache License 2.0 and is written primarily in Elixir, according to the GitHub repository. The README labels the release a “low-key engineering preview for testing in trusted environments.”

What We Know

Symphony is structured around two layers: a written specification (SPEC.md) that any team can implement in any language, and an experimental Elixir reference implementation under elixir/README.md, as outlined in the Symphony repository. The split is deliberate — the spec defines the service contract, while the reference implementation shows one way to ship it.

According to the SPEC.md, Symphony is “a long-running automation service that continuously reads work from an issue tracker (Linear in this specification version), creates an isolated workspace for each issue, and runs a coding agent session for that issue inside the workspace.” The orchestrator polls Linear on a configurable interval — defaulting to 30 seconds — and dispatches new issues to agent workers as concurrency slots free up.

The SPEC.md also defines how agents are launched and supervised. Workers are started via bash -lc <codex.command> inside a per-issue workspace directory. Each run progresses through a defined set of phases — PreparingWorkspace, BuildingPrompt, LaunchingAgentProcess, StreamingTurn, and Finishing — before reaching one of five terminal states: Succeeded, Failed, TimedOut, Stalled, or CanceledByReconciliation. Stalled sessions are detected through inactivity monitoring with a five-minute default timeout, and failed runs are retried with exponential backoff.

The Linear integration is implemented through GraphQL queries against https://api.linear.app/graphql, authenticated with a LINEAR_API_KEY environment variable, the SPEC.md shows. The Elixir reference implementation, documented in elixir/README.md, launches the OpenAI coding agent in “App Server mode” and exposes a linear_graphql tool inside agent sessions, letting Codex make arbitrary GraphQL calls back to the issue tracker. The reference stack also pulls in Phoenix — including LiveView, a JSON API, and the Bandit HTTP server — to surface a minimal observability UI, and caps agent turns at 20 by default.

InfoWorld reports that Symphony components “monitor issue states, restart agents that crash or stall, manage per-issue workspaces, watch CI, rebase changes, resolve conflicts, and shepherd pull requests toward review.” The same report cites a 500% increase in landed pull requests on some internal OpenAI teams during the first three weeks of using Symphony — the headline metric OpenAI is using to justify the spec’s release.

Reception has been notable. GitHub shows the openai/symphony repository has accumulated more than 21,000 stars and over 1,900 forks since the public release.

How the Workflow Hangs Together

From a developer’s perspective, the operating model inverts the usual coding-agent loop. Rather than an engineer opening a session and prompting an agent step by step, Gizmodo summarizes Symphony’s pitch as “every open task gets an agent, agents run continuously, and humans review the results.” The board is the queue; the agents are the workers; the engineer is the reviewer.

That shift is also why the spec leans on a WORKFLOW.md file checked into the repository. According to the SPEC.md, the workflow file is parsed as YAML front matter plus a prompt body, defining tracker kind, workspace root, agent limits, lifecycle hooks, and the Codex command string. Keeping that policy in-repo means it lives under version control alongside the code the agents are modifying — a small but pointed bet that orchestration policy should be reviewable like any other change.

What We Don’t Know

Symphony’s headline figure — a 500% increase in landed pull requests — is OpenAI’s own internal claim, reported by InfoWorld. It is presented as applying to “some internal teams” over the first three weeks, with no third-party benchmark and no comparison cohort disclosed. How those gains translate to teams outside OpenAI — particularly those without OpenAI’s harness engineering, automated tests, and guardrails — remains an open question.

It is also unclear how broadly the spec will be adopted. The repository is explicit that this is an engineering preview, not a product, and the GitHub README recommends running it only “for testing in trusted environments.” Whether other agent vendors and issue-tracker providers will implement compatible runtimes — and whether OpenAI will keep iterating on the spec — will determine whether Symphony becomes an interoperable standard or a single-vendor reference.