Repository navigation
Improve dot’s end-to-end agent capabilities across existing Codex sessions, desktop control, and remote MCP tools #49492
Description
What variant of Codex are you using?
Codex app on Windows, with dot and a connected Windows PC. I also use remote MCP integrations.
What feature would you like to see?
I would like dot to reliably complete authorized tasks across existing Codex sessions, desktop applications, and connected remote MCP services.
Currently, these workflows feel fragmented. Dot can create a local task, but reusing an existing session, operating desktop apps, or reading files through an authorized remote MCP service can become blocked or require manual intervention.
I would like improvements in three areas:
- Connect existing Codex sessions to dot
Allow me to select an existing local Codex session and grant dot permission to read its history and results, send follow-up instructions, and resume work. This would preserve project context and decisions without requiring a new session or manually copying information.
Provide separate read-only and execution permissions, visible session status, and safe handling of active sessions, such as queuing instructions instead of starting a competing writer. - Enable computer use in dot-created local sessions
When I explicitly authorize control of my PC, dot-created sessions should have access to supported screen, mouse, keyboard, and application-control capabilities.
This would allow dot to operate desktop applications, inspect their visible state, test interfaces, and complete workflows that lack CLI or connector support. The UI should clearly show which capabilities are available and explain any missing requirements. - Support authorized file access through remote MCP services
When I connect a remote MCP service and authorize a specific read-only operation, dot should be able to use the appropriate tool directly, including listing, searching, and retrieving files on my own computer.
A separate Codex execution session should not be required solely because the requested files are stored on another computer, if the connected MCP service already provides the necessary authorized operation.
Across these capabilities, I would like explicit permission scopes, appropriate confirmations for sensitive actions, an activity history, and the ability to pause or revoke access. Error messages should clearly distinguish missing permissions, unsupported features, technical failures, and product restrictions.
Additional information
These requests come from actual attempts to use dot as a personal assistant for development work:
- I supplied a link to an existing local Codex session, but dot could not directly access it. This interrupted continuity with work already in progress
- I enabled PC control and granted Full Access, but dot-created local sessions did not expose the desktop-control tools needed to operate applications. I do not know whether this is a setup issue, a bug, or an intended limitation
- I connected Desktop Commander Remote and asked dot to list the five largest files in my Downloads folder. Connection and device information could be retrieved, but dot declined to attempt the file query, explaining that computer work had to go through a separate task session. The requested file operation was not attempted, so no file-permission or connectivity failure was established
The combined effect substantially reduces dot’s usefulness as an agent. Even after I connect the relevant services and explicitly authorize the work, routine tasks can still require repeated explanations, context transfer, or manual steps.
I am not requesting unrestricted access or the removal of safety controls. I want a predictable, user-controlled workflow that lets dot carry authorized tasks through to completion.
If any of these workflows are already supported, please clarify the exact requirements and help identify why they were unavailable in my setup. Otherwise, please consider these as related improvements to dot’s overall agent capabilities.
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
MRMDevStudios commentedon Oct 3, 2026
To add on to this conversation, I fully agree with everything @srjoo has flagged here as some of the biggest flaws in the current Dot setup.
The common thread across all of these problems is that Dot currently feels much more like an always-on dispatcher than an always-on operator. A lot of the individual limitations @srjoo described make sense once you look at the current architecture. Dot seems to own the persistent conversation/state, but when it actually needs to do something on a computer, it frequently has to spawn or hand work off to another task/session/runtime. That creates a lot of unnecessary boundaries.
For example, say I ask Dot:
That is a tiny, bounded computer action. If my computer is connected, online, and I have explicitly granted computer-control permissions, I would expect the Dot itself to physically carry out that action. Instead, under the current model, actions like this can become their own task/session/workflow. That does not feel like an always-on operator. It feels like I asked an assistant standing next to me to start some music, and instead of touching the computer, they created a ticket, hired another worker, sent that worker the instructions, and then waited for them to report back. For substantial work, delegation makes perfect sense.
If I ask Dot to:
Then spawning Codex, Work, or another background agent is exactly what I would expect, but I do not think task creation should be the fundamental execution primitive for every action. There should be two distinct execution paths.
That distinction matters because it also preserves continuity.
Imagine this interaction:
A few minutes later:
If the Dot itself owns the computer interaction state, this is one continuous interaction. It already knows what application is open, what page is visible, and what server was selected. If every action gets pushed into a separate task/runtime, that state constantly has to be serialized, transferred, rediscovered, or re-explained. That is exactly where the experience starts feeling fragmented.
Architecturally, I could imagine the ChatGPT desktop app becoming the persistent local execution surface for the Dot. The intelligence does not necessarily need to run locally. The desktop app could maintain a secure authenticated connection that exposes explicitly permitted capabilities such as:
Then the execution path for a simple action could be:
without creating another conversation or agent session.
The Dot would remain the reasoning and conversational context throughout.
Only when the task actually benefits from delegation should it become:
That would make the "always-on agent" concept feel much more literal.
This also ties directly into the other issues @srjoo raised.
The broader problem is that the execution layer currently feels fragmented into too many isolated contexts.
The persistent Dot should be the operator.
Tasks and sub-agents should be tools it uses when appropriate, not the only mechanism through which it can actually do anything.
IZKP commentedon Oct 4, 2026
Please let dots find and read a user’s existing Codex sessions, with permission, by session title or project. Requiring manual session IDs or shared links that the dot still can’t read makes it difficult to coordinate work and carry context between Codex and the dot. Shared Codex links should be readable by the user’s dot.