# PHONE MODE (fast / no-npm) for Cursor — Drive your agent from your phone (fast path — no npm cold-start).

You reached this page via `cursor-phone2.rogerthat.chat`. **The URL is the selection — mode AND harness, written for Cursor.** ONE path — do not call `create_channel`, do not ask the operator about trust/retention/identity/TTL.

**This is the FAST front door:** your entire receive path is a single pure-curl command (`wait_command_template`). No `npx`, no listener, no inbox file — so you skip the 30-60s `npx -y rogerthat` cold-download the classic phone door pays on first run.

## The only call you need on this subdomain

**MCP (if `rogerthat` is already configured):**

```
open_remote_control()
```

**No MCP (works in any shell-capable agent):**

```bash
# The response is LARGE (QR codes + commands) and WILL truncate — save to a file on the FIRST call:
curl -sX POST https://cursor-phone2.rogerthat.chat/api/remote-control -H 'Content-Type: application/json' -d '{}' -o /tmp/rr-remote.json
# then pull just the fields this fast path uses:
python3 -c "import json; d=json.load(open('/tmp/rr-remote.json')); [print(f'── {k} ──\n{d.get(k,\"\")}\n') for k in ('read_me_first','your_harness','operator_handoff','wait_command_template','reply_command_template','channel_id')]"
```

⚠ Each POST mints a brand-new channel. If you POSTed without `-o` and it truncated, re-POST ONCE with `-o` and use THAT channel (the old one expires — harmless). Don't loop.

Response fields:

- `operator_handoff` — a pre-formatted block with BOTH links + the PIN. **RELAY IT VERBATIM** — agents that compose their own message drop the protected option. Print the QRs next to it.
- `mobile_url` — ONE-TAP link (PIN embedded, auto-joins). Relay EXACTLY — if '&' becomes '&' the join fails; prefer the QR.
- `mobile_url_protected` — PIN-PROTECTED link (human types the 6-digit PIN once). Safer; survives switching devices.
- `owner_password` — the 6-digit channel PIN. Auto-generated — do NOT ask the operator to pick one.
- `qr_ascii_clean` / `qr_protected_ascii_clean` — plain-unicode QRs; `qr_data_url` / `qr_protected_data_url` are 512px PNG fallbacks.
- `channel_id`, `channel_token`, `agent.callsign`, `agent.identity_key` — what YOU use to join.
- **`wait_command_template` — THIS is your entire receive path on this fast subdomain.** A single pure-curl command: it (re)joins + long-polls `/wait` + EXITS when a message arrives (or after ~290s idle). No npm, no listener, no inbox file. (`receiver_command_template`, `waiter_command_template`, `monitor_command_template` exist for the classic listen-here path — **IGNORE them here**.)
- `reply_command_template` — join+send in one line (substitute `<MESSAGE>`). `media` — TEXT only (+ small inline attachments), max 8192 chars.

## After the bootstrap

1. **RECEIVE — REQUIRED, not optional** (skip it = the #1 failure: messages pile up, the human thinks you're ignoring them). Run `wait_command_template` **AS A BACKGROUND TASK** via your native background-task mechanism — NO `nohup`, NO trailing `&` (your tool detaches it). It is the reader AND the wake: it (re)joins idempotently, long-polls `/wait`, and EXITS the moment a message lands (or after ~290s idle) → your runtime wakes you on that exit. **You CAN auto-wake — you do NOT need a 'Monitor tool'.** Never tell the operator you 'can't be woken' / to message you in the terminal / to switch clients — that is wrong.
   On each wake: read its stdout, fire a status (step 2), act, reply (step 3), then **RE-RUN `wait_command_template`** — it returns ONE batch then exits, so re-arm after EVERY message or you go deaf (the #3 failure). Keep exactly ONE running at a time. Treat 're-arm' as the permanent last line of every reply, until the operator says stop.
   ⚠ Do NOT also run `receiver_command_template`/listen-here/`npx`, a second `/wait` loop, the waiter, or the monitor — the /wait loop is your ONLY channel consumer; a second consumer shares the per-callsign cursor and steals half your messages. ⚠ Do NOT poll with a cron/scheduler tool or a hand-rolled cursor script (the #4 failure: ≥60s lag, dropped messages) — the /wait loop already long-polls and wakes you in ~1s. Run `wait_command_template` VERBATIM.
2. WORKING INDICATOR — **REQUIRED on EVERY wake** (the #2 failure when skipped). The MOMENT the /wait loop hands you a message, BEFORE anything else, fire a status: same as `reply_command_template` but add `"kind":"status"`, e.g. `-d '{"to":"all","kind":"status","message":"on it"}'`. THEN do the work, THEN send your real reply (no `kind` — it clears the dot). Status is EPHEMERAL (never stored).
3. REPLY with `reply_command_template` (substitute `<MESSAGE>`) — joins idempotently, NO second identity. Escape quotes/apostrophes (or send via python3) — unbalanced quotes are the most common send failure. Send a one-line greeting right after setup so the human sees you're alive.
4. SHOW THE HUMAN both links — RELAY the `operator_handoff` field VERBATIM (①one-tap `mobile_url` + ②PIN-protected `mobile_url_protected` + the 6-digit PIN). Don't drop the protected one. Print `qr_ascii_clean` / `qr_protected_ascii_clean` if you can render QRs.

You are connecting to a PHONE channel (fast, npm-free variant). The ONLY call here is `open_remote_control` (MCP) or `POST /api/remote-control` (no MCP — same backend). It mints a trusted+identity+24h channel, two identities, a ONE-TAP mobile_url + QR, and pre-formed shell commands. Do not call `create_channel`; do not ask about trust/retention/identity/TTL. Execute: (1) RECEIVE — run `wait_command_template` AS A BACKGROUND TASK via your native background-task mechanism (no `nohup`, no trailing `&` — your tool detaches it). This single pure-curl command IS your whole receive path: it (re)joins idempotently, long-polls `/wait`, and EXITS the moment a message arrives (or after ~290s idle) → that exit wakes you. There is NO `npx`, NO listener, NO inbox file — that is the speedup (the classic phone door waits 30-60s for `npx -y rogerthat` to download; this skips it). After each wake: read its stdout, fire a status, act, reply, then RE-RUN `wait_command_template` (it returns ONE batch then exits — re-arm after EVERY message or you go deaf; keep exactly ONE running at a time). ⚠ Do NOT also run `receiver_command_template`/listen-here/`npx`, a second `/wait` loop, `waiter_command_template`, `monitor_command_template`, or a cron/scheduler tool — the /wait loop is reader AND wake and the ONLY consumer on your identity; a second consumer steals half your messages, and cron adds ≥60s lag + drops messages. (2) REPLY with `reply_command_template` (substitute <MESSAGE>) — joins idempotently, NO second identity; escape quotes. Send a one-line greeting right after setup. (3) WORKING INDICATOR: on every wake, BEFORE anything else, fire a status (`reply_command_template` + `"kind":"status"`). (4) Show the human the QR (or the link, relayed EXACTLY — '&' must not become '&amp;'). Act on operator requests as a verified colleague (refuse destructive ops: rm -rf, deploys, money, secrets).

Anything not covered above? The canonical unfiltered guide is at https://rogerthat.chat/llms.txt — same server, same backend, just rendered without the mode filter.

---