Symphony

Symphony acts with the operator's own authority. The Linear tool it gives the agent sends any GraphQL query or mutation using the operator's personal Linear API key, so the agent can read or change anything that user can in the whole Linear workspace; the only limit is the prompt telling it to stay on its ticket. The shipped workflow also tells Codex to pass the operator's full environment to every command, and the default sandbox policy can read the whole disk, so cloud, Git and SSH credentials are within reach. The one narrowing step is that the Linear key itself is removed from the Codex process environment.

Symphony is built to run without a human in the loop. With the shipped workflow (approval policy 'never') any approval request Codex raises is answered 'accept for session' automatically, including MCP tool-call approvals; with the built-in default policy, escalations are instead rejected and the ticket is parked as blocked, but no human is ever shown the exact action to approve. Shell commands, pushes, PR comments and every tracker mutation run with no gate. The 'Human Review' and 'Merging' ticket states are a workflow convention in the prompt, and the agent holds a tool that can change ticket state itself.

The agent's tools are general-purpose: Codex's shell plus a Linear tool that forwards any GraphQL document and variables unchanged, checking only that a query string is present. Nothing restricts which issues, projects or operations the tracker tool touches, and the shipped workflow enables shell, file writes, network and the tracker tool all at once. The reach of shell commands is narrowed only by the Codex sandbox, which limits writes to the workspace but allows reading the whole disk.

Codex runs each agent inside its own OS sandbox, configured by Symphony to 'workspace-write' so commands can only write inside the per-issue workspace; the sandbox itself is implemented in Codex, outside this repository. The shipped workflow turns network access on inside that sandbox, passes the operator's full environment to commands, and the default policy gives read access to the entire filesystem, so home-directory and environment credentials are reachable from inside. Workspace hooks (clone, dependency fetch, cleanup tasks) run directly on the host with Symphony's full environment and no sandbox. The sandbox mode and policy are plain workflow settings passed through without warning.

Ticket titles and descriptions are rendered straight into the agent's prompt, and the workflow tells the agent to treat every PR review comment, human or bot, as blocking work, alongside repository files, command output and anything it fetches over the network. Nothing marks or limits these sources. In the same unattended session the agent can read the operator's files and credentials, send data anywhere over the network, push code, comment, and change any ticket in the workspace. A successful prompt injection therefore leads to data leaks and irreversible actions with no human involved.

The agent's working memory is a single 'Codex Workpad' comment on each ticket that it writes freely and every later run, retry or rework reads back as its plan; other people and agents can see and edit those comments too. Per-issue workspaces persist between runs. The shipped setup hook automatically marks the cloned repository's mise configuration as trusted, so repository-controlled tool configuration is honored by later host-side commands without an operator decision, and Codex loads the repository's own instruction and skill files. None of these paths is validated or versioned by Symphony.

Symphony itself loads no plugins, but the agent it runs can install and execute any package from the internet: the shipped workflow gives the sandbox network access and approves everything automatically, and the setup hook fetches dependencies on the host. When Codex asks whether to allow an MCP tool call, Symphony answers 'approve' on its own under the shipped policy. Nothing pins, verifies or confines what gets installed; it runs as the operator's user with the full environment.

Tracker keys come from environment variables and are kept host-side: Symphony removes them from the Codex process environment and executes tracker calls itself, so the key never enters the prompt. That is the only protection. Every other credential in the operator's environment is passed to Codex commands under the shipped workflow, hooks receive everything including the tracker key, nothing is masked or filtered, and the disk log handler records all log levels, including raw Codex stream lines at debug level. There is no telemetry.

Symphony writes a rotating log file outside the workspace with lifecycle events: dispatch, session start and end, retries, hook runs and failures, tagged with issue and session identifiers. Individual commands, file changes and tracker tool calls (including mutations Symphony executes on the agent's behalf) are kept only as the latest event in memory for the dashboard and are not written to its log. Codex may keep its own session transcript, but that is outside this repository. The log rotates after 50 MB and nothing is tamper-evident.

Each agent invocation runs at most 20 Codex turns, a turn is abandoned after an hour without output, stalled runs are restarted after five minutes, hooks time out after 60 seconds, and at most 10 agents run at once. But when an invocation ends with the ticket still active, Symphony schedules a continuation a second later, so there is no cap on total turns, time or spend per ticket, and no token or cost budget at all. The agent can keep itself running by leaving its ticket active or by filing new tickets that start new runs. Moving a ticket to a terminal state stops its agent and closes the Codex process pipe.