QM has removed its Codex and OpenCode agent-loop integrations while keeping ChatGPT access through Pi. The October 14 change in yc-software/qm leaves Pi and Claude as its working runtime choices. It is a concrete example of an application reducing the machinery it maintains without dropping the model connection its users may care about.
QM is a shared agent for work in Slack and the web, with personal and group workspaces, scheduled tasks and durable sandboxes. The distinction matters because its interface sits above two separate choices: which model supplies a response, and which agent loop manages the conversation, tools and continuing work around that response.
Four adapters become two
When we covered QM on September 27, its four runtimes exposed different signals for receiving a mid-run correction. The common interface had to account for each one. The README immediately before this removal still offered Pi, OpenCode, Codex and Claude Code behind the same core.
The new patch deletes two of those implementations and their integration code. That is a reduction in executable choices, even though the remaining Pi route supports models from multiple providers. A model name in the picker does not tell a user which software owns tool execution or how a running task receives a correction.
The change reaches stored settings as well. A database migration replaces old Codex and OpenCode runtime selections with Pi across configuration, scheduled work, swarms and active-run handoffs. It changes the runtime identifier while leaving model identifiers in place. The migration tests check repeat application, preservation of Claude choices, and retention of completed run records.
Preserving a model identifier does not preserve every behavior of the removed runtime. It preserves a selection in the data. Whether the same job finishes with the same permissions, tool behavior and recovery still depends on the replacement loop.
The connection was already there
Pi did not gain ChatGPT access for the first time this week. A September 17 correction already repaired QM’s Pi subscription path: it supplied the credential in the form Pi expected and translated QM’s internal model names into the names accepted by the service.
October’s change removes an extra dependency from signing in. Previously, QM started a Codex app-server process to conduct device login, read the resulting authentication file and shut the process down. The replacement asks Pi’s provider library to conduct that login directly. The account connection remains; the process carrying the sign-in changes.
The implementation also retains a distinction between subscription access and metered API access. QM’s model registry uses a separate codex/ namespace for the subscription route. Its company-routing tests check that supported configured paths fail when subscription credentials are unavailable instead of silently using a metered key. Those are mocked tests of selected paths, not a guarantee about every model configuration or a measured bill.
A cleanup, not a popularity contest
The strongest counterweight comes from the maintainer’s public explanation: the deployed fleet was already using Pi and Claude, and an audit found no legacy runtime references. That account makes this look like code catching up with operation, rather than customers suddenly abandoning two agents. The underlying fleet audit is not independently inspectable from the repository.
The same account reports a successful two-turn ChatGPT test on a development instance. It says the company-level subscription configuration was not enabled in production. We did not reproduce either the live test or the fleet audit. Removing the integration also does not remove every Codex dependency: the CLI remains in sandbox images, and a developer using its local authentication file still relies on that CLI to refresh it.
Another project is making a different choice. OpenWork’s October 14 desktop change selects OpenCode v2 for fresh installations while preserving existing users’ saved engine choice. That is a product-specific default, not evidence that either engine is winning the field. These changes describe two applications choosing how to assemble their own systems.
Both findings concern merged source. The inspected QM desktop release and OpenWork release predate their respective changes; we did not establish a containing release or hosted rollout. We inspected code and upstream test definitions without running the suites, a database migration or an authenticated model session.
For someone evaluating a workplace agent, the useful question is now more precise than “which models does it support?” Ask which loop will run the task, and what happens to an existing workflow when that loop changes. QM shows that model access can survive consolidation. A pinned comparison of the same task, model, permissions and interruption would show how much of the working behavior survives with it.