A developer has described how he connected regular ChatGPT conversations to his Windows laptop and a VPS, then used separate chats to work through GitHub issues in parallel. Custom MCP servers supplied the tools; OpenAI’s Secure MCP Tunnel supplied the connection.
In his November 1, 2026 post, the author describes conversations that could inspect repositories, edit files, execute commands, run tests and interact with applications visually. He says this let him perform development work through his existing ChatGPT subscription without consuming his separate Codex allowance.
That distinction is about to matter less. OpenAI’s usage guidance says Plus, Pro and Business subscribers will share a token-based allowance across ChatGPT and Codex starting in December. Instant chat remains exempt.
The useful lesson is how the developer assembled tools, task descriptions and shared state into a workable agent system. His account is a single developer’s report, not an independently verified performance or cost comparison. Despite his provocative headline suggesting responsibility for OpenAI’s change, he explicitly qualifies that suggestion; there is no established causal connection.
MCP Gives ChatGPT Access to the Development Machine
The developer’s setup uses MCP, the Model Context Protocol, to expose capabilities on his machines to ChatGPT. A conversation can request a tool action, receive its result and use that result to decide what to do next.
That connection changes what a coding conversation can accomplish. Without machine access, a model might suggest a patch for someone to copy into an editor. With suitable tools, it can inspect the actual project, apply changes and request a test run.
The author describes this connection path:
- A regular ChatGPT conversation requests a tool action.
- OpenAI’s Secure MCP Tunnel connects ChatGPT to a tunnel client on his computer.
- A unified local MCP gateway routes the request to the appropriate backend tool.
- The tool performs the operation and returns its result to the conversation.
His gateway is a Node.js router that aggregates multiple tools. A similar setup runs on his VPS, allowing development capabilities to live on either machine. According to the developer’s account, he authenticated the connection using an API key and did not need to build separate cloud infrastructure merely to bridge ChatGPT to his laptop.
Two open-source projects supplied the main capabilities:
| Component | Role in the reported setup |
|---|---|
| Desktop Commander | File access, code reading and writing, terminal commands, tests and process management |
| CUA, or Computer Use Agent | Screenshots, mouse interaction, button clicks and visual inspection of browser or desktop applications |
Together, those tools cover both code-level work and interface inspection. A worker can modify an application through filesystem tools, then use computer interaction to inspect the resulting interface.
I’d treat that breadth of access as the most consequential setup decision. File editing, terminal execution and desktop control carry different risks. Anyone building a similar system should decide which directories, processes and credentials the tools can reach before making them available to a conversation. The post’s API-key authentication detail does not, by itself, explain those permissions.
GitHub Issues Become the Agent Queue
The developer did not describe a parent conversation automatically creating and controlling a fleet of subagents. He says ChatGPT conversations could not spawn or control subchats in his workflow, so he coordinated separate conversations himself.
GitHub issues provided the handoff between planning and execution.
His process began with a more capable reasoning model, such as the model he identifies as Astra in Codex or the limited Pro model in ChatGPT. He asked it to create an implementation plan, then divide that plan into issues containing enough context, requirements and acceptance criteria for another agent to work independently.
The execution loop looked like this:
- Plan the overall change. Use a premium model for architecture and difficult decisions.
- Create bounded issues. Give each task a clear scope and completion criteria.
- Open separate ChatGPT conversations. The author identifies his workers as Sol 6 High conversations.
- Assign different issues to different chats. Each conversation accesses the project through the MCP tools.
- Reserve premium usage for harder work and review. Routine implementation stays with the worker conversations.
These are the model labels in the author’s account, not a recommendation about current model availability. The important architectural choice is the separation between planning, task specification and execution. His post describes those stages explicitly.
An issue becomes a durable task packet. A fresh conversation can read it without needing the planner’s entire conversation history. That makes requirements and acceptance criteria especially valuable: they carry the intent that would otherwise remain buried in another chat.
My view is that task decomposition is the more reusable contribution here. Connecting tools gives an agent capabilities. Writing an issue that can be completed independently gives it a manageable job. Parallelism works best when both are present.
Shared Files Make Coordination a Real Constraint
The worker conversations shared access to the same filesystem through the MCP setup. That makes collaboration straightforward, but it also creates a practical collision risk.
Two chats can receive different issues and still touch the same file. A component change might overlap with a styling task; a dependency update might alter the environment while another worker is testing. Those are implications of shared mutable files, not independently observed failures in this setup.
GitHub issues help define ownership, but they do not isolate edits. I’d start this pattern with tasks that have clearly separated file ownership, then serialize changes to shared configuration, dependencies or database migrations. Separate branches and working directories are another option, although they add integration work.
The author also spent time improving how tool results appeared inside ChatGPT. He reports adding a custom MCP App viewer so captured screenshots could be displayed directly in the conversation, plus improvements to tool responses and monitoring.
That screenshot detail is useful. A model receiving an image and a person being able to inspect that image are different interface requirements. Making screenshots visible helps the operator understand what the agent is seeing. It still leaves the operator responsible for deciding whether that evidence demonstrates that the task is complete.
December Changes the Budget Behind the Workflow
The author’s economic argument depended on keeping two usage pools separate.
He reports that his regular ChatGPT worker conversations did not encounter the Codex-style limits he was trying to conserve. Although those workers were slower than premium models, he could run several conversations while saving scarce premium usage for planning, difficult decisions and review.
He also says the tunnel and MCP integrations required no separate paid API inference calls. That is a narrower claim than free development: he still used an existing ChatGPT subscription, his machines and a VPS. The reported advantage was avoiding an additional model API bill while shifting implementation work away from his constrained Codex usage.
OpenAI’s December policy changes that accounting boundary for Plus, Pro and Business plans. ChatGPT and Codex will draw from a shared allowance, measured in tokens, the units of information models process and generate.
OpenAI says consumption will depend on the selected model and the task, with more advanced models and complex tasks generally using more allowance. Its explicit exception is:
Frequently Asked Questions
3 questions
1Can regular ChatGPT conversations work as coding agents?
In the developer’s reported setup, yes. Custom MCP tools gave conversations access to files, commands, tests and computer interaction. The capabilities depended on those connected tools.
