How My OpenAI Dot Starts Real Claude Code Sessions on My PC

A developer built a tool called Remote Hands that lets an always-on OpenAI Dot agent, running in the Codex desktop app on Windows, start real Claude Code sessions on a PC without keyboard input. On 2026-10-07, a single chat message triggered a Claude Code session that leased an Android phone, ran a Google search, captured the AI Overview text, released the phone, and reported back in about six minutes. The developer notes the agent cannot yet hold a conversation inside a running session, which is the next piece of work.

Orion is my OpenAI Dot: an always-on agent I message from ChatGPT. It lives in the Codex desktop app on my Windows PC, which lets it run commands there. Claude Code is where my engineering runs. I wanted Orion to be able to hand Claude a job without me at the keyboard. On 2026-10-07 it did. I asked Orion to have Claude use one of my agent phones to Google a question and bring back what Google showed. A real Claude Code session started on my PC, ran the search on the phone, and Orion put the answer in our chat. This guide walks through what made that work: a small tool I call Remote Hands, built over about ten days, and the checks around it. It covers starting a session. Orion can't yet hold a conversation inside a running session; that is the next piece, and I say so where it matters. The code is linked at the end. Who this is for: anyone who wants an always-on agent a Dot, a Grok Bot, a scheduler, a phone to start real coding-agent sessions on their own machine, without handing it a keyboard. On 2026-10-07 at 2:06 PM Pacific, one chat message to my Dot became a real Claude Code session on my PC, and about six minutes later that session had its answer, which Orion relayed to our chat. In between, the session leased an Android phone, ran a Google search, captured the AI Overview word for word, released the phone, and reported. What I sent Orion, typos included: "We could demo the right now. I know it'll work. Tell Claude to use phone A to Google search for 'what is OpenAI dot' have report back with the Google ai summary that shows up and you give me back that text." What came back: "It worked: Claude used Phone A, searched Google, expanded the AI Overview and returned the text. Phone A was released afterward." The exchange with Orion. The 3:12 PM stamp marks the later follow-up; when Orion relayed the result isn't logged. The logs on the PC put times on every hop: | Time PT | What happened | |---|---| | 2:05:54 PM | A health check reaches the Remote Hands service | | 2:06:52 PM | Orion's prompt is written to a file on the PC | | 2:06:58 PM | The start request reaches the service, which accepts it 2.3 seconds later | | 2:07:04 PM | Orion's brief arrives as the new session's first message | | 2:07:43 PM | The session leases the phone | | 2:09:06 PM | The search is submitted | | 2:12:03 PM | The phone is released | | 2:13 PM | The session gives its final report | Most of those six minutes were the job, not the plumbing. The brief asked for the whole AI Overview, expanded and scrolled, plus every source card. The start itself took seconds. For a live demo I'd ask for the first result's title and link instead. The brief Orion wrote is worth reading, because it set the session's scope. Its authorization paragraph began: Authorization covers this search and browser/device navigation, capturing screenshots and result evidence in a temporary folder. No purchases, account changes, unrelated messages, app installs/modifications, repairs, deployments, board edits, claims, memory writes, publishing or changes to other work. It also told the session to label the result "Google's generated overview, not independently verified product facts", and, if a sign-in, CAPTCHA, or permission barrier appeared, to "report it without bypassing it." None blocked the search, but something close showed up. Right after Chrome launched, its first-run sign-in page flashed onto the phone screen. The session left it alone, and by the next screenshot Google was showing normally. Its report noted the moment and said plainly: "I don't know why it cleared." Report, don't touch: that's the behavior I want. What the Claude session saw on the phone at 2:09 PM, cropped from its own evidence screenshots. Google's overview, not verified facts. Because keystrokes are the wrong tool for a start. In tests from 2026-09-29 to 2026-10-07, keyboard input couldn't reach a locked PC, and opening Claude's chat panel with a prompt only pre-fills the box without sending it. A terminal opened by an editor extension works locked or unlocked, stays out of the windows I'm using, and leaves an audit line. So for starts, Orion never drives my screen. It asks a service for one thing, a new Claude session in a given folder with a given prompt, and the service does it in a way I can audit. Two live checks settled it. Behind the lock screen, a start in an already-open window was ready in 7 seconds and a brand-new window in 17. And in three live checks, a start never typed into a window I was working in. Through four hops on one machine. Orion runs a CLI, the CLI posts to a Windows service that listens only on 127.0.0.1, the service asks a Cursor extension, and the extension opens a terminal running Claude Code. In live checks on 2026-10-05 and 2026-10-06, a start in an open window was ready in 8.2 seconds, and opening a new window took 45. Four hops, all on one machine. Every hop checks the request again. hands . hands health check comes 40 to 90 seconds before each of Orion's starts. Orion writes its prompt to a file, then runs hands start-claude with a folder, a request id, and the prompt. claude --session-id <uuid5 of the request id \ --remote-control <label --name <label -- <prompt Two details in that line do real work. The session id is derived from the request id, so a replayed request can only ever point at the same session. And --remote-control makes the session show up in the Claude app on my phone, so I can watch it or take over. It guards the start, not the session. As of 2026-10-07 the service has three actions: a health check, an early typing self-test that only types into its own scratch window, and the one that does real work, starting a Claude session. Both the service and the editor extension check every start. Once the session is running, Claude Code's own permission mode decides what it can do. What every start is checked against: repo must be inside one of ... . Folder paths with control characters or ${...} variable syntax are refused too, because Cursor would substitute the variable. -- , which ends option parsing. That alone isn't enough, so the service also refuses a prompt that starts with - , a one-word prompt, and control characters other than tabs and newlines. hands off makes every start fail with service off until it's switched back on. What it doesn't limit, and I'd rather name it than hide it: So if your Claude Code skips permission prompts, the brief is the only scope a started session has. Start with prompts on, and have the calling agent write its scope into the brief anyway, the way Orion did. Only partly, so far. Claude Code writes each session to a JSON-lines file, and as of 2026-10-07 the read-back command polls that file by session id every 2 seconds for the session's first reply after the prompt, capped at 4,000 characters and treated as untrusted text. That confirms a session took its brief. It doesn't return the final result. In the demo, the first reply was the session acknowledging its scope, at 2:07:12 PM. I have no log of how Orion collected the final result, so I won't claim a route. Orion's first real start, on 2026-10-06 at 8:11 PM, shows why "started" and "done" have to stay separate. It told me: "Remote Hands opened a new Cursor window at 8:11 pm with Claude running ... I haven't verified Claude's first reply yet." That's the honesty I want from an agent: it said what it knew, and no more. Six failures between 2026-09-29 and 2026-10-07 became fixes, and one is still unexplained. Most were Windows and editor behavior: a lock check that lied, a chat panel that can't send, two Claude prompts that stalled unattended sessions, lost log lines, and slow refusals. desktop locked: false on a locked PC. It now reads the session's lock flag instead. needs human after 180 seconds. The bridge now pre-trusts folders, but only inside the allowed roots. As of 2026-10-07, Orion can start a Claude Code session and hand it a brief, and that's all. It can't hold a conversation inside a running session yet. That is the next slice: send a message, read back the reply, repeat. Codex and Grok sessions, approvals, and voice come after that. Two live checks are still open too: a start when Cursor isn't running at all, and confirming that Claude terminals don't come back on their own after Cursor restarts. I'll update this guide when those land, rather than describe them as working now. Give the always-on agent a verb, not a keyboard, wherever a verb exists. For starts it does: one checked action allowed folders, a prompt that can't become options, one submit per request id, a kill switch, a token on loopback beat screen automation on every axis I measured. It works with the screen locked, stays out of my windows, and leaves an audit trail. The plan for Codex and Grok will need paste and Enter where a harness has no launch route, behind the same checks. Then remember what the contract doesn't cover. It guards the start, not the session. Decide the permission mode before you point an always-on agent at it, and make the agent write its scope into every brief. The code is public: remote-hands https://github.com/OrionArchitekton/remote-hands , MIT, with 636 Python and 212 bridge tests. It's experimental and does what this guide says: it starts sessions. Originally published at danmercede.com https://www.danmercede.com/guides/openai-dot-starts-claude-code-sessions .