ChatGPT dots With Multiple Computers: A Safer Coding Workflow

OpenAI now lets a single dot connect to multiple local computers and choose a machine for a task. The practical use is straightforward: keep working on your laptop while a dedicated computer handles a build or test run. The part worth designing carefully is how the task identifies its target.

An agent with access to two machines can encounter two checkouts, two sets of dependencies and two different versions of the same branch. Giving it more places to work makes an environment check more useful, not less.

What the announcement confirms

The OpenAI Developers announcement confirms multiple local computers per dot and per-task computer selection. Its example is building and testing an application on a dedicated machine while the user keeps coding on a laptop.

The post does not establish that every file, dependency or browser session is automatically synchronized between machines. Build a workflow that checks for those inputs rather than assuming a second computer starts with the first computer's state. Nor should a multi-computer announcement be read as a promise that one running build can move between machines without restarting.

Connect the computer that will do the work

OpenAI's getting-started guide says local access is optional and initially off. Connect a computer through the ChatGPT desktop app on that machine and approve access. Local work appears in separate sidebar tasks. Revoking access prevents subsequent work on that computer.

For an organization, member consent and workspace policy are separate requirements. The workspace administration guide says local computer access is off by default for Enterprise, and the connected machine needs to remain online with ChatGPT open. It also describes restrictions for workspaces with operating-system-specific Codex or ChatGPT Work policies.

Do not grant access to a machine merely because it is faster. A build worker should contain the repositories and development resources appropriate for the work you intend to delegate. Production credentials and unrelated customer files make the consequences of an overly broad task larger.

A task brief that makes the target explicit

Here is an illustrative prompt for an existing, authorized development setup. Replace the machine and repository names with your actual ones. It is a workflow template, not a report of a test performed for this article.

Use the computer named Build Mac for this task, not my laptop.
Work in the existing checkout at <repository path>.

Before changing anything, report the repository remote, branch,
commit and whether the working tree has uncommitted changes.
Check the project instructions and required runtime versions.
Do not discard local changes or switch to a different machine silently.

Run the repository's documented test command against that commit.
Return the command, exit status, failing tests and relevant log excerpts.
Do not push changes, deploy, or update dependencies for this test-only task.
If the requested machine or required input is unavailable, report the gap.

This brief makes three decisions visible: where work runs, what state is under test and which actions are allowed. It also separates a request to run tests from permission to repair code or alter the environment.

Check that the result belongs to your change

Suppose the laptop contains an uncommitted fix while the build machine contains yesterday's main branch. A green test run on the second machine says nothing about that fix. Before treating the result as evidence, confirm the exact commit or transferred patch and any files that the test depends on.

For committed work, the simplest audit trail is usually a commit identifier plus the test command and result. For uncommitted work, define how the patch will reach the target and verify its contents there. Avoid describing a machine by an ambiguous role such as “the fast one” when there are several similar environments.

The same care applies to browser-based tests. A local browser may have a particular login, test account or extension configuration. A result from another browser is meaningful only if it exercises the intended state. Sharing access to a computer is not proof that every dependency of the task is present.

What to do when the computer is unavailable

Keep the task's execution requirement explicit. If a test requires a device-specific toolchain, a substitute environment may produce a different answer even when the code compiles. Ask for the missing prerequisite or approve a clearly identified alternative before interpreting the result as equivalent.

For lengthy work, request a durable output location and a short final record of what ran. A test log or patch should be retrievable after the conversational update, especially if you will review it from a different device.

Multiple computers make it easier to keep interactive work separate from expensive builds. The workflow becomes trustworthy when the reported result identifies the machine, the code and the checks well enough that another engineer could reproduce it.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain developer tools and practical AI workflows in clear, useful stories.

Book a 30-minute call.