Why I built Symphony Studio
Autonomous coding agents can move quickly, but an operator still needs a trustworthy answer to four questions: What is happening? Why is it happening? Is the result valid? What needs attention next?
I built Symphony Studio as a proof-driven Mission Control for that gap. It is an Apache-2.0 downstream fork of OpenAI's open-source Symphony, submitted as a tested Build Week preview checkpoint while the longer v1.0/v1.1 roadmap remains outside this entry's claims.
It is for developers and engineering leads supervising autonomous coding work who need to know when to intervene and what evidence they can trust. Its distinctive contribution is a Symphony-native chain from bounded intent and explicit write authority to authoritative runtime state and fail-closed evidence—not another agent chat or inferred-status dashboard.
Symphony stays at the core
This is not a replacement or a mock of Symphony. Symphony remains the runner: Linear is the source of work, WORKFLOW.md is the repository-owned policy contract, eligible issues receive isolated workspaces, a bounded orchestrator owns dispatch and reconciliation, and Codex App Server performs implementation work.
Studio adds the operator and evidence layer around that engine:
New Work turns a prompt or Markdown specification into a bounded proposal before any Linear write. Setup exposes repository, Linear, Codex, model-policy, and readiness truth without rendering credentials. Mission Control projects authoritative runtime events and labels missing usage or evidence as unavailable. Run Detail is designed to connect an objective to criteria, commands, files, checks, review, and sealed evidence; missing runs fail closed. A canonical intent service, fail-closed Linear write boundary, local reset contract, browser oracle, and protected release evidence support the UI.
Upstream and Build Week work are separated through UPSTREAM_BASE, SPEC.md, STUDIO_SPEC.md, BUILD_WEEK_DELTA.md, the fork policy, and the patch ledger.
What the submitted checkpoint actually demonstrates
The recording comes from a fresh detached Linux checkout of the exact submitted source, 1853afcd0c7a48a187b5afa15f585399cbf623c5, in a sandboxed in-app browser—never from my desktop or personal browser. The runtime was launched loopback-only with credential variables stripped.
The real working flow shown is:
submit the committed safe Markdown intent; inspect the actual repository read-only; produce a five-task dependency-aware proposal; present an explicit approval boundary stating that no Linear mutation has occurred; inspect Setup, Mission Control, Run Detail's fail-closed missing-run state, the public fork, and the published limitations.
The interface does not turn missing authority or missing evidence into theatre.
How Codex accelerated the build
Most of the downstream Build Week work was developed in one primary Codex task. Codex traced the upstream system, converted the product specification into bounded release packages, implemented code and tests together, generated protocol-schema evidence, exercised failure paths, repaired gate findings, and maintained exact checkpoints through a long security-sensitive release process. Independent agents were used for bounded review and diagnosis, not as a substitute for the primary implementation task.
How GPT-5.6 Sol Ultra was used
GPT-5.6 Sol Ultra was the primary Codex conductor for Build Week. It handled architecture and product decisions across the Symphony runtime, Linear boundary, Phoenix LiveView interface, security model, tests, and release evidence, and coordinated deterministic validation plus fresh independent review.
That is a build-time contribution. The submitted checkpoint does not claim a completed live GPT-5.6 run inside the product.
Supported platform and tested launch path
Current checkpoint: Linux x86_64, local loopback only.
Prerequisites: git, mise, Python 3.10+, Node.js 18+, and Codex CLI 0.144.3. git clone --branch release/v0.2.0-buildweek-preview.1 \ https://github.com/farhaanlevy/symphony-studio.git cd symphony-studio mise trust mise install cd elixir mise trust mise install mise exec -- mix setup cd .. ./scripts/preview/run preflight --live --json ./scripts/preview/run launch --live-preflight --port 4000
After the launch command succeeds on the judge’s Linux machine, open http://127.0.0.1:4000/setup in a browser on that same machine. This is a local loopback preview, not a hosted demo. See the full owner/judge checklist and preview limitations.
A fresh detached Linux checkout of 1853afcd… completed the documented dependency setup, passed all seven live preflight checks with Codex CLI 0.144.3, launched on an isolated loopback port, and served the real Setup, New Work, Mission Control, and Run Detail routes without a Linear credential. The recorded New Work flow inspected 1,500 repository files, resolved bounded clarification, produced five dependency-aware tasks, and then showed publication as unavailable with zero Linear mutation.
Why the recorded Setup frame says “Not ready” and “+ changes”: the safe demo deliberately omits Linear credentials, so publication readiness must fail closed. The “+ changes” marker comes from untracked, demo-generated evidence after the clean exact-head preflight; no submitted source was modified. This is a preview checkpoint, not a production-ready release.
Honest preview boundary
This is not complete v1.0.0 or v1.1.0. No live Linear write was performed, no real Codex product execution occurred, and the golden path was not completed. The submitted preview deliberately hard-disables approval, publication, Start, and live Linear mutation; a separately reviewed out-of-process broker is required before those capabilities can be enabled. The current public checkpoint also does not claim a demonstration issue or finished Run Detail evidence. Mission Control is therefore honestly empty and a missing run is explicitly unavailable. Remote access, history, analytics, deployments, collaboration, remote workers, non-Codex providers, and later-release planning features are out of scope.
No credentials, private browser state, cookies, private tokens, personal protected paths, or private reasoning are included in the repository or submission media.
Category: Developer Tools Source - submitted preview branch: https://github.com/farhaanlevy/symphony-studio/tree/release/v0.2.0-buildweek-preview.1 License: https://github.com/farhaanlevy/symphony-studio/blob/release/v0.2.0-buildweek-preview.1/LICENSE Upstream base record: https://github.com/farhaanlevy/symphony-studio/blob/release/v0.2.0-buildweek-preview.1/UPSTREAM_BASE
Built With
- elixir
- gpt-5.6-sol-ultra
- linear
- openai-codex
- openai-symphony
- phoenix-liveview
Log in or sign up for Devpost to join the conversation.