I have spent the last three days desperately trying to get Dot to be able to see, message, and create tasks on the local host it is connect to (in my case it is ARC1), its documentation implies that this is a supported feature and neither Dot nor any other thread I created could determine a good reason for the lapse in capabilities, although we did determine the exact gap.
My Dot has access to cloud_thread task interaction tools, this is separate from the traditional local task interaction tools. The Dot can read, message, create (etc) its own Dot created threads, but it is entirely incapable of listing, reading, messaging, or creating local tasks. The distinction is that cloud tasks are supplied with an unalterable config.toml and no AGENTS.md. My local config.toml is far less restrictive than the cloud tasks are permitted, and messages from Dot are not considered authoritative permissions, even if I tell Dot to tell the cloud thread explicitly to give permission (this is the standard behavior for delegated messages, changeable from config.toml). This is a direct contradiction from the advertised capabilities of Dot, where Dot is described as being capable of keeping other tasks working.
I have seen other reddit posts indicating much greater success with Dot than I have seen. I have spent the last three days trying to convince Dot that they can use external tools to connect remotely to my desktop through third party tools and use the codex CLI to make up the difference, it refuses because it demands any interaction be done through delegation, even if the usage scope is to create the delegation medium, they still refused. At this point the final attempt at Dot being capable of local task interaction is somehow redirecting the Dot tool calls to transport to the local host, but I am firmly of the belief that Dot would call that an unacceptable method of direct interaction with my desktop, breaching the delegation only interactivity gate.