ACP Sessions Should Resolve the APC Project From cwd
When an editor talks to an agent runtime, one small design choice decides whether project context stays portable or turns into editor glue.
That choice is project resolution.
APC is the portable context layer. It defines the project contract through AGENTS.md, .apc/, agent files, skills, and other repo-owned artifacts. APX is the daily-use runtime and tooling layer on top of that contract. It serves the daemon, CLI, web admin, Telegram bridge, and now the ACP surface that IDEs can launch.
So when an ACP client starts a session, APX should not ask, "Which editor is this?" It should ask, "Which workspace folder is this session running in?"
That is why resolving the APC project from cwd is the right boundary.
What apx acp actually does
The ACP surface in APX is intentionally thin. apx acp serves the protocol on stdin/stdout so editors like Zed or JetBrains can spawn it as a subprocess. But the ACP server is not a second runtime. It is an adapter over the same local daemon APX already uses elsewhere.
The docs are explicit about this: each ACP prompt becomes a streaming super-agent turn on the code channel. That means ACP gets the same coding prompt and tool set as apx code, instead of inventing a separate editor-only behavior.
That part matters, but the first important step happens even earlier: session/new.
Why cwd is the right key
In src/interfaces/acp/index.js, APX requires cwd to be an absolute path before it opens a session. Then resolveProjectForCwd() walks upward from that path until it finds the nearest APC root. If no APC project exists there, APX returns an error telling you to run apx init first.
If a project already exists in the daemon, APX reuses it. If not, it registers that root path with the daemon and continues.
That is a strong design for two reasons.
First, it keeps APC portable. The project identity comes from the repository layout and .apc/, not from hidden editor metadata. Open the same repo in two IDEs and APX still lands on the same project contract.
Second, it keeps APX practical. The runtime still does the daily work: loading the project, opening the session, streaming tool activity, and keeping follow-up turns coherent. But it does that by reading APC from the workspace, not by replacing APC with editor-owned state.
The alternative gets messy fast
Imagine the opposite design.
An ACP server could create a project identity from the editor session itself, from a client name, from a temporary window id, or from a custom cache under one IDE's private folder. That might look convenient at first, but it breaks the APC/APX split.
Now the same repo can mean different things depending on which GUI launched the agent. Sessions drift. Project registration becomes opaque. Moving from one editor to another stops feeling like switching surfaces and starts feeling like switching products.
That is exactly what APC tries to avoid.
APC should travel with the repo. APX should make that repo usable in daily work. If APX starts anchoring project identity to editor-specific state, the portable layer loses authority.
Why this also improves the chat loop
The benefit is not only project discovery.
Once APX resolves the project from cwd, the ACP prompt path stays clean: prompts stream through the daemon on the code channel, and completed turns are kept in the session's in-process history so follow-up prompts keep context without inventing daemon-side ACP session storage.
That means the editor surface stays small:
- APC owns the durable project contract.
- APX owns runtime execution.
- ACP owns transport between editor and runtime.
Each layer does one job.
That is the deeper lesson here. A good agent surface should contribute transport, not identity. cwd already tells APX where the project lives. APC already tells APX what the project means. Once those two facts stay in place, the editor can remain a thin client instead of becoming a second source of truth.
For APC and APX, that is the healthier tradeoff: portable context from the repo, practical execution from the runtime, and no editor-specific project magic in the middle.
Top comments (1)
Resolving project context from cwd is boring in the best way. It matches how developers already think about terminal state, and it reduces the chance that a session silently attaches to the wrong project. The key is making the resolved project visible at session start.