AI coding agents after launch: Codex CLI, OpenCode 2.0 and Cursor Projects

Three of the coding-tool launches we have stamped share a design idea. Codex CLI 0.157.0 started a background server for interactive sessions. OpenCode 2.0 rebuilt itself around a single background process shared by every client. Cursor Projects added a coordinator agent that plans larger work and hands it to many cloud and local agents.

In each case the new architecture shipped as described. What users found in the days and weeks after launch is that a long-running process in the background changes how things fail. This article compares the three receipts claim by claim. Two are stamped Partly; Cursor Projects is still Too early.

Codex CLI 0.157.0: a daemon users didn’t ask for

OpenAI’s release notes for 25 September included this line: “Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible.”

It did start automatically. But on some Windows and Arch Linux setups, the “recovery choice” was a hard error telling users to rerun with --no-daemon. One Windows issue, open with 63 comments and 50 reactions when we last checked, reports a daemon privilege error where the previous version worked. Another Windows start-up failure was reproduced by maintainers and fixed in a 0.157.1 hotfix. A third report, with 153 comments, described terminal windows flashing open and shut on every request; fixes landed in later releases.

The report that drew the most attention was not a crash. A CLI user documented that opening a session now starts a persistent daemon that keeps running after every window closes, copies a package of about 374 MB into the Codex folder and runs an hourly self-updater. They asked for it to be opt-in. That request reached the Hacker News front page with 607 points and 292 comments, where the default-on, self-updating daemon was the main complaint.

The one-line release note doesn’t mention any of that. The other claims in the release, such as GPT-6 Sol and Luna support and longer upload timeouts, drew no solid reports either way. Verdict: Partly.

OpenCode 2.0: one service, one point of failure

The OpenCode 2.0 post said: “In 2.0 this server now automatically runs as a single background process on your machine.” That is true, and the design has a clear upside: every client shares the same state. The downside is that when the service fails, every client fails with it.

Users reported several ways that happened:

• After upgrading a long-lived v1 database, a migration error stopped the service from starting at all. Maintainers could only reproduce it on a hand-edited database, and the reporter fixed it with a manual SQL workaround.
• On Windows, the service could not bind its port after an update, so the CLI would not start. Maintainers pointed to ports reserved by WSL2 mirrored networking.
• Because MCP state now lives in the service, a remote MCP server that fails once, for example after a laptop sleeps, is never retried until the service restarts. A maintainer said laptops that sleep on a corporate VPN regularly hit this.
• On macOS, the service’s memory kept climbing in image-heavy sessions; maintainers reproduced steady growth with large image attachments.

The post also said: “There are a lot of other changes but they are backwards compatible.” The same post lists three breaking changes, and one user reported that the automatic v1-to-v2 migration dropped 6,238 older assistant messages across 92 sessions. Hot-reload, another headline promise, did not work when the config folder was a symlink or on a Nix build.

Two things work in OpenCode’s favour. Most early reports got maintainer attention within days, and some problems turned out not to be OpenCode’s fault: Windows scrolling lag was traced to Windows Terminal’s font fallback. We found no solid reports yet on code mode, the feature many people were most curious about. Verdict: Partly.

Cursor Projects: in use, but the big promises are untested

Cursor’s changelog made the boldest claim of the three: “It maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted.”

Seven weeks after launch, nobody had reported testing any of that at scale. What users did report is about the edges of the design:

• The coordinator kept working from an old checkout because it doesn’t pull merged changes. Staff said this is expected today and suggested asking it to pull.
• Local MCP servers that work in the editor are unavailable in Projects, because the coordinator always runs as a cloud agent.
• A coordinator kept switching to a different model than the one picked, because another bot was setting it. The user only noticed on their bill.
• Runtime secrets did not reach agents in one Project that still pointed at its temporary repository.

There is real praise too. One heavy user said Projects made them much more productive working solo, though it gets awkward when a team shares a Project. And the availability claim, “Projects are available in beta and rolling out to all users starting today”, holds. Because the headline promises are still untested, the receipt stays Too early.

What the three launches have in common

Put side by side, the receipts show a pattern worth knowing before you upgrade an agent tool:

• Background processes outlive your session. Codex’s daemon keeps running after the window closes and updates itself. OpenCode’s service holds state for every client. That is convenient until something goes wrong, and then the fix is often “restart the service” or “run without the daemon”.
• Upgrades carry state forward, including broken state. Long-lived v1 databases and packaged Linux installs were where the start-up failures clustered.
• Cloud-first agents lose local context. Cursor’s coordinator can’t see local MCP servers or merged changes unless you ask.
• Release notes undersell the change. A one-line note about “background-server startup” doesn’t tell you about a 374 MB copy and an hourly updater.

A caveat about our sources

Most of the reports on these three receipts come from GitHub issues and vendor forums. Those lean negative, because people file issues when something breaks, not when it works. People whose upgrade went smoothly rarely post about it, and for Codex the new server works as written for many people. We count praise when we find it, and we say on each receipt where the reports came from. The full rules are on our method page.

Before you upgrade an agent tool

1. Read the release notes for anything that runs in the background, and find out how to turn it off.
2. Back up local session data before a major version that migrates it.
3. Check the project’s open issues for your operating system and install method.
4. For cloud agents, check which of your local tools and settings they can actually reach.

All three receipts are linked above with every claim and report, and new coding-tool launches go into the archive as we stamp them.