At first, putting conversation and code work in a panel beside the page seemed convenient. During development I came to care more about using the tools already built from the same external conversation. That change in priorities led me to remove the embedded CLI and make the browser a local execution host reached through MCP.
Being beside the page was not the only form of convenience
An internal conversation put the request close to the visible page. But when interpretation, next-action selection, diagnosis and execution all continued inside the app, it became harder to explain which responsibility belonged to the browser and which belonged to the agent. If the existing plugins could be used from an external conversation, I needed to reconsider the value of another judgment interface.
The development record contains the request to disable the embedded CLI first and test external control while preserving tabs, logins, plugins and Jupyter. Removal followed. I do not describe that sequence as one finished design executed without revision. It was a change of boundary made after using the product.
I defined the execution host rather than removing judgment
Fresh judgment now belongs to the connected external Codex conversation. The browser owns the actual session, tabs, execution state and stop controls. Receiving an external command does not justify silently switching accounts or repeating a dispatched mutation. Wherever the decision is made, the actual action still follows the established verification path.
This separation supports running an existing plugin without invoking another model inside the browser. It does not erase the cost of the external agent's decisions. Nor does a disconnected client erase execution state. The conversation and the run need separate lifetimes so a later connection can read what happened and continue appropriately.
The connection uses a fixed entrance to the same browser
The external MCP server presents a stdio interface and connects to the authenticated local pipe of the running app. Commands and arguments pass strict contracts. Context inspection, schema discovery, plugin execution and status reading have distinct operations. This is not a browser-control interface that adds arbitrary page JavaScript or a general shell command.
There is no need to publish a connection token or machine-specific credential path in a usage article. Host configuration that locates the connection is different from the public capability contract. The connection also remains within the local operating-system user's environment. A pipe is not proof that the entire computer is sandboxed.
External access should not bypass the UI's execution rules
MCP operations reuse TaskController and ActionBroker, tab leases, native input and actual result checking. Creating a weaker executor for external commands would make rules disappear depending on the entrance used. I therefore separated a new control entrance from a new grant of authority.
A run also does not become complete merely because the external conversation ends. Its state and pending outcome must be inspected and the original expectation established. That can resemble an ERP discussion about a save response, but the boundary here is specific: a native input dispatched to a browser and the observable result of that same input.
The transition needed to preserve the work already present
The removed parts were the embedded model and CLI gateways and their runtime, UI and IPC entry points. The transition was not performed by deleting old conversations and settings from disk. Existing tabs, logins, plugins and notebooks had to remain usable from the external conversation. Removing code required an explicit inventory of what should survive.
Archived source remains historical regression and recovery material, not a feature to load automatically into the current product. When reading later code and documentation, I check the date and current wiring whenever an old embedded-model description appears. A completed transition and retained historical records can coexist.
Questions I would ask before building another agent tool
For another program operated by an agent, I would first identify who interprets the request, who retains execution state and who verifies the outcome. Convenience does not require every responsibility to occupy one process. As procedures repeat and conversations grow, a boundary that can be explained becomes useful for maintenance.
This is a maker's account checked against the current external-control contract and the removal record. I did not reinstall the original app or test customer accounts while writing it. It is not a promise that one architecture is always faster. The important change was how a judgment reaches an executable tool and how responsibility remains visible afterward.