Getting started · · 7 min read
Connect your iPhone without another account
The computer shows the pairing QR. The phone scans it. A Mesh invitation is a different action.
GrantTap connects a phone to a local computer that already runs your coding tools. You do not need to add GrantTap under Codex Connected accounts, and a chat message cannot substitute for device pairing. The connection must be confirmed through the local GrantTap helper and the phone.
Think of this as adding a trusted controller to a computer. A Mesh is a separate collaboration scope; joining one does not pair a device to the computer network.
Start on the computer
Install the compatible GrantTap plugin and granttap-mcp runtime, then run granttap setup. Open the GrantTap connection card in the coding app and choose Add a device. That card displays a short-lived, one-time QR; granttap.com/connect handles coding-app approval and observations. Never paste the QR into chat or a support ticket.
If the card cannot contact the helper, check that the local helper is running and the plugin uses the same protocol version. A relay being online only proves one part of the route. It does not prove that an approval hook, background sync, or this phone is ready.
Finish on the phone
In GrantTap on iPhone or iPad, open Devices → Add a device (Scan QR). Scan the code shown by the computer and confirm the computer identity on both sides. The computer then appears in Connections. Repeat the same process for each additional Mac or PC; scanning a second computer adds a link rather than replacing the first.
An already trusted phone may show an expiring QR for another controller in its Settings. That joins another iPhone or iPad to the device network. It is separate from inviting a person into a particular Mesh, which has its own role and access choices.
Check the whole path
After pairing, verify that the computer reports Live, that the intended coding app has its GrantTap hooks or plugin active, and that a real task event reaches the phone. A saved pairing record and a green relay light alone are insufficient. If a coding app was open before installation, restart that app so it loads the new integration.
Keep the QR private until it expires. If the wrong device was added, revoke that link in Connections and pair again with a fresh code. Do not share a Mesh merely to make a phone able to manage your own computers.
Pairing is a trust decision
The QR step is deliberately short lived because it authorizes a new controller for a particular computer. Before scanning, confirm that the code appears in the GrantTap panel on the computer you meant to add. A code forwarded through a chat, copied into a ticket, or photographed by someone else has lost the physical context that makes pairing understandable. If anything feels ambiguous, close that attempt and start a fresh one on the intended machine.
A successful scan is not a general invitation into every Project. Device trust answers whether this phone may communicate with this computer. Project membership answers which people may see or act within a shared scope. Keeping the two decisions apart reduces accidental access: adding a second personal computer does not silently add coworkers, and accepting a Project invitation does not secretly enroll a new controller for your laptop.
What to verify on both screens
Read the computer name and the pending action before confirming on the phone. Afterward, look for that computer in Connections and compare its status with the panel on the desktop. A familiar name is useful for recognition, but it is not a cryptographic proof by itself; names can be reused. The pairing flow must tie the confirmation to the active one-time exchange, while the interface helps you recognize which machine you are dealing with.
For a practical smoke test, keep the coding application open and trigger one ordinary Task event. Confirm that the phone shows that Task under the expected computer and provider. This checks more than whether the relay has a connection. It checks that a provider integration observed work, the local helper forwarded it, and the phone could display it. If any link is missing, diagnose that link rather than repeating pairing indefinitely.
When the connection appears incomplete
A common source of confusion is the difference between installed, running, and integrated. A package may exist on disk while its helper is stopped. The helper may be online while a coding app has not loaded a newly installed plugin. A task may be visible locally but not yet delivered to the phone. Those are separate observations. Check the helper and integration status on the computer, then repeat the small live-event test before treating the setup as complete.
If the phone is offline, an absent update does not establish that the Task disappeared. Return to the computer, confirm the Task in the provider, and let the connection recover. Likewise, a message marked queued is not the same as a message accepted by the provider. The status should preserve that distinction. This is especially important for approvals: a delayed notification must not be mistaken for an action that was already allowed or denied.
Adding more than one device
People often use a desktop at home and a laptop while traveling. Pair each computer explicitly, then give each a name that helps you choose the correct target when continuing a Task. Do not rely on a folder name to identify the machine; several computers can have a checkout called the same thing. A route should refer to a particular host and provider session, and the phone should show enough context to prevent an accidental command on the wrong computer.
A second controller phone is another trust relationship. Add it through the supported Connections flow, then inspect the resulting device list. If a device is lost or sold, revoke its connection on the remaining trusted device or computer before pairing a replacement. Revocation and replacement are independent actions: a new phone does not make an old trust link disappear. Project member access may need separate review if that person or device also participated in shared work.
A small checklist after setup
The useful end state is not a pretty QR animation. You should be able to identify the paired computer, see whether it is currently reachable, find a Task from the intended provider, and tell whether a recent event was delivered. If an approval is requested, check its exact Task and action before responding. If you cannot explain what you are approving, leave it unanswered and inspect the computer. That pause is a feature of responsible remote control.
The illustration above is intentionally conceptual and the product capture below uses deterministic demonstration data. Neither is proof that your own pairing succeeded. The proof is the pair of confirmed devices and a real event on your own installation. The setup documentation and support page give the current installation steps; follow their version-specific instructions when labels or integrations change. This article explains what each step means so a successful connection is also an understood one.
