Repositories
One project can span repositories.
Repository-bound child issues run in verified checkouts. Their unlabeled parent waits for merges, then checks the combined result in an integration workspace.
A work system around the coding agent.
OpenSymphony coordinates multi-repository projects, dependency-aware task graphs, isolated workspaces, and OpenHands, Codex, or ACP execution in one local-first control plane. The desktop app and TUI expose repository routing, live runs, and the knowledge they produce.
Local-first control plane
Multi-repository project sets
OpenHands + Codex + ACP
Memory + code intelligence
Desktop operator surfaces
OpenSymphony
Operator surfaces
Harness
Execution stays attached to the issue.
OpenHands remains the default. Local Codex app-server and named ACP v1 profiles give each issue an explicit execution route, with session recovery and operator permissions where supported.
Knowledge
Completed work becomes project memory.
Memory capture and the knowledge graph preserve issue capsules, relationships, source references, and navigable context.
Desktop
The operator can see the system.
The desktop app connects task graph, run detail, changed files, and graph views so long-running work stays inspectable.
Why it matters
The operator sees the work, the run, and the knowledge it leaves behind.
OpenSymphony keeps coordination authoritative while each surface shows the evidence needed to decide what happens next.
01
The task graph routes work to the right repository.
Repository bindings, parent blockers, dependencies, and critical paths keep multi-repository work explicit before a workspace is created.
02
Runs retain their operational context.
Verified checkouts, OpenHands, Codex, and ACP sessions, run detail, retries, and recovery keep execution inspectable.
03
The system carries knowledge forward.
Memory capture and AST-backed code intelligence connect completed work to the files, symbols, diagnostics, and decisions it informs.
Operator surfaces
See the work at the level where decisions happen.
The desktop app brings task state and project memory into views that can be inspected, filtered, and followed back to their source context.
Task Graph
Dependencies become visible operating context.
Completed, Current, and Backlog panes show blockers, cross-pane relationships, and the critical path through active work.
Knowledge Graph
Completed work remains connected to what the project knows.
The Knowledge Graph groups project memory into navigable areas, concepts, capsules, relationships, and source references.
Workflow
From repository-bound work to an integrated result.
OpenSymphony routes each child issue to a verified repository checkout, runs the selected harness, and gives the parent a separate workspace for checking the merged result.
01
Route work to a repository
The orchestrator reads Linear hierarchy, dependencies, and explicit `repo:<alias>` labels before selecting dispatchable work.
02
Create a verified checkout
Each child runs in an isolated checkout of its bound repository with durable configuration, repository, and workspace identity.
03
Run through the selected harness
OpenHands is the default route, with local Codex app-server and named ACP v1 profiles available for explicit selection.
04
Integrate, inspect, and recover
After child merges, the parent checks the combined result in a separate integration workspace while operator surfaces expose blockers, evidence, and recovery state.
Quick start
Start with the repository's Quick Start.
You can follow the instructions without cloning the repository. When you want architecture docs, memory references, or deeper project material, use the Resources page.
Latest updates
Deep dives into the system
September 26, 2026
OpenSymphony 3.0.0 Adds Multi-Repository Projects and ACP Harnesses
OpenSymphony 3.0.0 routes one Linear project across multiple repositories and can run local ACP v1 agents through durable, operator-visible sessions.
July 28, 2026
OpenSymphony 2.11.0 Moves to Rust 1.97.1
OpenSymphony 2.11.0 adopts Rust 1.97.1 and Cargo Resolver 3, resolves the dependency mismatch that blocked some upgrades, and makes future CLI updates reproducible with a locked install.