Issue-Driven Managed Codex Sessions with Repo-Level State Engineering

[Proview-China]

I have been following this repository for a long time.

However, it still seems to be in a state that is not fully developed or productized yet, even though the problem it touches is clearly important.

If the long-term plan is for this functionality to be absorbed directly into Codex itself, rather than staying in Symphony, I can open a separate issue in the Codex repository instead. But if this direction is not already on the Codex roadmap, I would really appreciate it if you could take a moment to read through my thoughts.

I have spent time carefully reading Symphony’s codebase, and I think I understand the core idea: moving from Codex Cloud toward a more local and controllable workflow built around Codex App + Linear.

Relying on a more mature ecosystem to model and manage work makes a lot of sense. Linear’s issue-based workflow, for example, is a very strong foundation.

That said, Symphony has always looked somewhat underdeveloped to me, because it seems to be trying to extend Codex in two important directions:

1. hosted / managed tasks;
2. reducing unnecessary human intervention, while expanding the surface area through which humans can participate in work, instead of constantly steering Codex App with more and more prompts.

So in my view, the real responsibility of this component is essentially twofold:

1. automate the steps inside Codex App that should not require human operation, but that agents currently cannot reliably perform on their own;
2. make the granularity of hosted programming more controllable.

Based on that, I have the following idea.

We may not need fully isolated sessions. If the Codex App model is already becoming the industry benchmark, then Symphony should probably extend that model instead of creating a separate isolated workspace abstraction.

A simple git worktree-based approach may be enough. We can still rely on the traditional Git workflow.

Starting from a Linear issue, Codex can take the issue, analyze the current project state, then begin writing loop specs and producing a detailed implementation plan.

The session bound to that issue does not necessarily need to perform the actual coding itself. Instead, it can inherit the project state, analyze the tasks under the issue, and then manage multiple Codex sessions accordingly.

Recently, Codex App has already become capable of directly creating and interacting with human-visible sessions. These are not subagents. This model seems more observable and controllable.

So perhaps we can go one step further and dispatch a separate issue for maintaining a repo-level skill library.

This issue would be bound to a repo-anchored Codex instance, responsible for maintaining a skill library at the repository level.

For now, we might call this “State Engineering.” I am not sure whether that is the right name, but I suspect it is at least an early form of it.

In practice, what Symphony needs to do may be relatively simple:

• bind Linear;
• initialize the repository;
• configure Git;
• if the repository already contains meaningful code, start analyzing it and build the initial skill library;
• if the repository is still empty, prepare the project state and working structure first.

After that, every issue should inherit information from the repo-level skill library and the project state it maintains.

Then, based on the requirements in the issue, Codex would create the task spec and implementation plan, open new sessions, inherit the current project state, and execute the work according to the plan.

Once all tasks are completed, either serially or in parallel, the issue-anchored Codex instance would need to verify the result directly in Linear.

The verification artifact could be a screen recording, a screenshot, a tmux session, a webpage, or something similar.

If the user thinks the task has not passed review, they can continue giving feedback through the issue.

If the task passes review, the user only needs to mark the reviewed task as done in Linear.

Codex can then use the done state to update the project state. The repo-anchored Codex instance can inspect the diff, verify the changes, and run checks.

In this way, Symphony could quickly create controllable execution loops around issues, based on the current project state.

To be honest, I do not particularly like the word “loop” here, but it describes the mechanism well enough.

The important part is that the user no longer needs to constantly watch over Codex, especially if the user is not a developer.

I am not sure whether this direction overlaps with your own thinking, but I would be very interested to know whether this is aligned with the roadmap or whether you see the problem differently.