Skip to article
PlanToCodeDocs
Get the app

HandbookStart here

Setup: sign-ins, regions, and remote access

The parts of getting started that are not obvious: two unrelated sign-ins, optional API keys, one region per account, the remote-access switch, and the connected preview that precedes PlanToCode Pro.

Checked against the source on 17 September 2026

On this page

Two sign-ins and optional keys

Each sign-in covers its own stretch of the path from phone to OpenAI
Each sign-in covers its own stretch of the path from phone to OpenAIA turn sent from a phone travels through the regional server and the desktop app to the Codex child and on to OpenAI. The PlanToCode account covers the phone, the regional server, and the desktop app. The ChatGPT account covers the Codex child and OpenAI, including turns sent from a phone, and only its plan and usage limits travel back to the phone. An optional personal API key lets the desktop app reach OpenAI or Gemini without the Codex child. Without a PlanToCode sign-in on the desktop, phones cannot reach it. Signed out of ChatGPT, only new turns stop.
plan and usage limits reach the phone, the ChatGPT credential does not
Phone
Regional serverUS or EU
Desktop appRust runtime
Codexchild process
OpenAIor Gemini
your computer
PlanToCode account · one region
device list · relay · push alerts · phone dictation · 10-day preview
ChatGPT account
agent turns · usage limits
your API key
skips Codex
optional · desktop dictation · speech and video tools
No PlanToCode sign-in on the desktop: phones can’t reach it, and everything else on the desktop still works.
Signed out of ChatGPT: sessions, history, and files still open. Only new turns stop.
  • PlanToCode accountAuth0 · PKCE

    Each device signs in by itself, to the same account in the same region, and the desktop needs it only for remote access. If a phone can’t find the desktop, check this sign-in and the region.

  • ChatGPT accountaccount/login/start

    The Codex child signs in through your browser and runs every turn on it, including turns sent from a phone. If the agent won’t start a turn, check this sign-in and its usage limits.

  • Personal API keyopenai_api_key · gemini_api_key

    Kept in the desktop keychain for desktop dictation and, with a Gemini key, the speech and video tools. Phone dictation doesn’t use it, so check it only when desktop dictation fails.

One region per account

A PlanToCode account lives in one of two regions, United States or European Union, each with its own API host, relay process, PostgreSQL, and Redis. Device discovery is scoped to one account in one region, so both devices have to select the same one, and changing the region on a device signs it out first. The phones default to the United States when nothing is stored.

Remote access and the device list

  1. On the desktop, open Settings → Connections and turn on Allow Remote Access under Mobile Connection. Note the server region shown there.
  2. On the phone, choose the same region and sign in with the same PlanToCode account.
  3. Select your desktop from the device list, then choose a project and a session.
A desktop in the list is not always one that answers
A desktop in the list is not always one that answersFour example desktops pass three checks from top to bottom. The device list shows every desktop with a device row in the account’s region, connected or not. A desktop answers only while the socket it opened to the relay is live. An awake desktop answers the phone’s ping, and the phone loads projects, sessions, and the timeline. A laptop with its lid closed stays listed as online until the relay drops its silent socket after about 3 minutes, then counts as reconnecting for 90 seconds, then as offline. A desktop whose remote-access switch was turned off stays in the list but goes offline at once. A desktop in another region or account is not in the list.
Studio PConline
awake, switch on
Laptoponline at first
asleep, lid closed
Office Macoffline
switch turned off
not in the list
other region or account
Device rowin this region
Desktop socketto the relay
Ping answeredthrough the relay
loads projects, sessions, and the timeline
3 min
90 s
silent, then reconnecting, then offline
no answer at first
then -32011, then -32010
row stays
closed at once, no grace
relay answers -32010
no row in this region
  • Device rowPOST /api/devices/register

    Created with X-Client-Type: desktop the first time remote access is on, in the region the desktop chose. Sleep and the switch leave it in place, so the desktop stays listed.

  • Desktop socket/ws/device-link

    The desktop dials out to the relay, and phones never connect to the computer directly. A silent socket is dropped after about 3 minutes and counts as reconnecting for 90 s, while turning the switch off closes it at once.

  • Pingsystem.ping

    The phone opens its own socket for this desktop and pings through the relay. Only an answer lets it load projects, sessions, and the timeline.

The WebSocket register’s device UUID must match the row’s owner and role. The switch needs a chosen server location and a PlanToCode sign-in. That sign-in exists only for remote access, and every other desktop feature works without an account. A degraded saved session pauses the mobile connection.

The connected preview and PlanToCode Pro

The first phone on an account to reach a desktop starts a 10-day connected preview for the whole account. After that each phone needs PlanToCode Pro, bought through the App Store or Google Play for its platform. The subscription covers the phone only. Coding on the desktop needs nothing beyond the ChatGPT sign-in, and an iPhone subscription does not unlock Android or the other way round.

The preview clock belongs to the account, and Pro belongs to each phone platform
The preview clock belongs to the account, and Pro belongs to each phone platformAn example account with an iPhone and an Android phone. The iPhone gets the first answer from a desktop on day 0, and the regional server writes one preview record that ends 10 days later by the database clock. The Android phone first reaches a desktop on day 4 and gets the same record, so its preview also ends on day 10. After that the iPhone runs on an App Store subscription, which does not unlock the Android phone, and the Android phone needs its own Google Play subscription, bought here on day 12. The record stays expired and never starts again.
iPhone
Android phone
Preview recordregional server
preview
App Store Pro
same window
Google Play Pro
10 days · database clock
expired, never restarts
PUT /api/billing/workspace-preview
first desktop answer: record written
second phone: same record
ends for both phones
iPhone Pro does not unlock Android
day 0
day 4
day 10
day 12
example days
  • Preview recordaccount_workspace_previews

    Written the first time any phone on the account gets an answer from a desktop, with started_at from the database clock and expires_at 10 days later. Later phones get the same record, and the server can’t update or delete it.

  • Identity keysHMAC-SHA256

    The record is stored under keyed hashes of the Auth0 subject and the verified email, linked to each other. A lookup follows the links and takes the earliest start.

  • PlanToCode ProStoreKit · Google Play

    Bought per platform. The iPhone checks StoreKit on the device, and Android sends the purchase to the regional server to verify. Neither unlocks the other.

The server stores the preview under keyed hashes of the Auth0 subject and the verified email and counts the 10 days from database time.

iOS: StoreKit, the connected preview, and push

How purchases are checked on the device.

Android: Google Play Billing and the connected preview

How the regional server verifies a purchase.