Two documented Claude Code recovery options, --continue and --resume, are listed in the official CLI reference: Claude Code CLI usage.

Symptom: Your iPad or travel laptop disconnects while Claude Code is working, and you lose visibility of the task.

Fastest fix: Keep the repository, toolchain, and long-running task on a cloud Mac. Use the iPad or lightweight laptop as the remote interface. Keep a local fallback when you must work offline.

This is the right setup for independent developers who travel with only an iPad or lightweight laptop but still need macOS tools. It also fits remote technical workers moving between cafés, hotels, and coworking spaces who cannot afford to rebuild an environment after every device problem.

Last updated August 20, 2026. Current Claude Code and remote-access facts were checked against the official Anthropic and Apple documentation listed below. Availability, pricing, delivery, and connection behavior must be checked against the current MACCOME service page before you commit to a travel period.

Start with the execution decision, not the installation

A local terminal tied to your travel device creates a hidden dependency. The device must stay awake, the network must remain usable, the terminal session must remain available, and you must still have the right credentials when Claude Code asks for approval.

That fails easily. Imagine switching from café Wi-Fi to a phone hotspot while a local terminal is open on an iPad-connected laptop. The terminal closes during the transition. You return to the project with no clear task context, no confirmed test result, and no reliable record of the last requested action.

The better division is simple:

  • Cloud execution: repository, runtime, dependencies, logs, tests, and long-running Claude Code tasks.
  • Local access: iPad or lightweight laptop, SSH client, browser, or controlled desktop connection.
  • Local emergency path: a minimal checkout, documentation, credentials procedure, and enough tooling to make a critical offline fix.

This is not a claim that every remote process will continue after every disconnection. It is a design choice that removes the travel device from the center of task execution. You still need to test session behavior, recovery commands, authentication, and approval prompts on your actual setup.

Decide by task characteristics

Task condition Preferred location Reason
Requires macOS tooling or a macOS-only build environment Cloud Mac or local Mac The task depends on the operating system, not just a web browser
Requires long execution while you move between networks Cloud Mac The host is less exposed to local Wi-Fi changes
Must run without usable internet Local device Remote access cannot replace an offline environment
Requires physical hardware, local USB access, or nearby test devices Local device A hosted machine cannot provide every physical interface
Contains sensitive approval or production actions Dual-track with manual review Remote access adds an identity and access boundary that must be controlled
Needs frequent switching between iPad, laptop, and borrowed devices Cloud Mac The project state stays in one primary environment

The long-term choice is therefore not “remote or local” for every task. It is a routing rule. Put repeatable online development on the remote host. Keep offline and hardware-dependent work local.

Before departure: prepare a recoverable project

Preparation should create a small, documented environment. Do not copy an old Mac wholesale. A full migration also copies stale credentials, unused services, hidden shell changes, and assumptions about local paths.

Step 1: classify the project

Mark each project with three labels:

  1. Operating-system dependency: Does it need macOS, a specific SDK, Xcode, signing access, or another Mac-only component?
  2. Connectivity dependency: Can the task pause safely, or does it need an active service, approval, or external endpoint?
  3. Sensitivity: Does it touch production credentials, customer data, private repositories, or deployment systems?

Then choose one of three routes:

  • Remote-first: macOS-dependent and normally online, with changes that can be reviewed remotely.
  • Local-first: frequently offline, hardware-dependent, or impossible to authorize through your travel connection.
  • Dual-track: sensitive, high-impact, or difficult-to-recover work that needs both a primary cloud environment and a local fallback.

Step 2: write the recovery note

Store a short runbook outside the travel device. It should contain:

  • Repository locations.
  • Required runtime and dependency installation steps.
  • The expected working directory.
  • Test and build commands.
  • How to identify the last completed task.
  • Which credentials must never be stored in project files.
  • The action to take when a permission prompt appears.
  • The person or channel responsible for escalation.

This note is more valuable than a large backup archive when you are using a borrowed laptop or a replacement tablet. A backup gives you files. A runbook explains how to resume work without guessing.

Step 3: verify the remote entry points

Apple documents remote login through SSH and screen sharing as separate capabilities. Read the Apple remote login guide and the Apple screen sharing guide before enabling either route.

Use SSH for:

  • Checking whether the host is reachable.
  • Inspecting repository status.
  • Reading logs.
  • Restarting a controlled process.
  • Working when graphical access is slow.

Use screen sharing for:

  • Inspecting a graphical tool.
  • Handling an action that requires the desktop.
  • Confirming a prompt that is difficult to interpret through a terminal.

Do not expose every account to every entry point. Use a dedicated account where possible. Restrict allowed users. Keep remote administration separate from ordinary project access.

Access route Best use while travelling Main failure mode Recovery requirement
SSH Fast status checks and terminal work Credentials, network path, or host unavailable A second approved device and tested login
Screen sharing Desktop inspection and graphical approval High bandwidth, frozen session, or restricted account SSH fallback and controlled user permissions
Web console Access from a device without a full client Browser session expires or lacks terminal features A documented alternate entry point
Local terminal Offline work and emergency edits Device sleep, loss, damage, or environment drift Minimal local checkout and rebuild notes

First launch: install only what the project needs

The official Claude Code installation documentation should be your authority for supported systems, installation, authentication, and updates. Do not use an unknown one-line installer copied from a forum or social post.

On the cloud Mac, establish the smallest working environment:

  1. Create or confirm the approved user account.
  2. Apply system updates according to your operating policy.
  3. Configure remote login or screen sharing.
  4. Install Claude Code using the current official method.
  5. Authenticate the account on the remote host.
  6. Clone only the active repository.
  7. Install the project runtime and dependencies.
  8. Run the existing test command before asking Claude Code to edit anything.
  9. Record the installation and recovery steps in your runbook.

The goal is not to reproduce every customization from your personal Mac. The goal is to produce a machine that can check out the project, run its tests, and show evidence of its state.

Keep the repository on the cloud host rather than editing a local copy and synchronizing changes manually across countries. Manual synchronization introduces merge conflicts, untracked files, stale dependencies, and uncertainty about which machine contains the latest change.

A cloud Mac workstation from MACCOME can be evaluated as the remote host for this workflow. Treat it as a test environment first. Confirm the available configuration, delivery method, access route, and current rental period on the service page before moving an important project.

Set permissions before delegating the first task

Claude Code can read files, propose changes, run commands, and request access to operations that affect the project or system. The permission boundary matters more when you are travelling because you may approve a prompt from a small screen, a poor connection, or an unfamiliar network.

The official Claude Code permissions and identity documentation should define your access model. Use the documented options. Do not treat a permissive configuration as a shortcut to reliability.

Begin with a low-risk task:

  • Ask Claude Code to inspect the repository structure.
  • Ask it to identify the test command.
  • Request a small documentation or test improvement.
  • Review the proposed diff.
  • Run the test suite.
  • Confirm that the working tree and commit history are understandable.

Then set three controls.

Permission allowlist: Decide which commands and project paths are routine. Keep deployment, credential access, destructive file operations, and production changes behind manual approval.

Version control checkpoint: Require a clean baseline before a larger task. Review the diff before committing. Push or back up approved changes through your normal repository process.

Task checkpoint: Define what “done” means before you disconnect. It may be a passing test, a generated file, a reviewed diff, or a written failure report. “The agent ran for a while” is not completion evidence.

Travel reminder: Never define success as “Claude Code kept typing while you were offline.” Define success as a reviewable change, a test result, and a clear stopping condition.

Use a controlled session for long tasks

Claude Code's CLI reference documents session continuation and resumption options. Use the official CLI reference to confirm the current syntax and behavior rather than relying on memory.

Your operating sequence should be:

  1. Start from the correct repository directory.
  2. Check the branch and working tree.
  3. Read the latest task note.
  4. State the allowed scope in plain language.
  5. Define the expected evidence.
  6. Start with a bounded task.
  7. Review output before expanding permissions.
  8. Save the result in version control or the project log.
  9. Stop when the evidence or the time limit is reached.

A long task needs an explicit stop rule. Stop when tests fail repeatedly, the requested files leave the agreed scope, a credential prompt appears, network access changes, or the output cannot be reviewed. When you are travelling, uncertainty is a reason to pause, not a reason to grant broader access.

If the task depends on a proxy or restricted network, consult the official Claude Code proxy configuration documentation. Do not infer that a working browser means the CLI can reach every required service. Terminal traffic, authentication, and certificate handling may follow different paths.

Rehearse the first disconnection before you need it

A travel-ready cloud setup is not proven by one successful login. Test the exact failures you expect:

  • Switch from café Wi-Fi to a phone hotspot.
  • Put the iPad or laptop to sleep.
  • Close the SSH client.
  • Reconnect from a second device.
  • Try the graphical entry point after an SSH-only session.
  • Check whether the task produced a log, diff, test result, or prompt.
  • Confirm whether the host is reachable even when the original device is not.

Use SSH to answer the first question: “Can I reach the host and inspect the project?” Use screen sharing to answer the second: “Can I see and control the desktop when the task requires it?”

Do not confuse a disconnected client with a completed or failed task. Reconnect, inspect the repository, check the process or session state, read recent output, and compare the working tree with the last known checkpoint.

If the cloud host is unreachable, move to the local emergency route. If only the graphical session fails, use SSH. If the host is reachable but Claude Code needs a new approval, do not approve blindly from a public network. Pause and review the request.

When travelling across regions, access may also be affected by local network policy, captive portals, DNS behavior, or corporate proxy rules. These are connectivity conditions, not proof that Claude Code itself is malfunctioning.

FAQ: the travel decisions that cause the most trouble

Can Claude Code be installed on a cloud Mac?

Yes. The cloud Mac must meet the current platform and account requirements in the official installation guide. Install Claude Code on the host where the repository and runtime live. Your iPad only needs a suitable remote access method. Confirm authentication on the host itself, then test a small repository inspection before starting development work.

Will an iPad disconnect interrupt a Claude Code task?

It can interrupt your control or visibility even when the host remains available. Whether a task continues depends on the terminal session, host state, task design, and current Claude Code behavior. Never assume persistence from a disconnected screen. Reconnect through SSH or a controlled desktop session, inspect the repository and logs, and use the documented continuation or resumption workflow.

How does a digital nomad check Claude Code remotely?

Use SSH for a fast text-based check. Confirm the host, working directory, branch, repository status, recent output, and test evidence. Use screen sharing only when you need graphical context or an approval prompt. Keep a short task log with the expected result and stopping condition. That makes a second device useful instead of forcing you to reconstruct the session.

What permissions should a cloud Mac expose?

Expose only the accounts and services needed for the project. Restrict remote login users, limit screen sharing, and separate project credentials from personal files. In Claude Code, keep sensitive operations subject to approval. Review every requested expansion against the task scope. If you cannot explain why a permission is needed, stop the task and investigate before granting it.

Is a local MacBook better than a remote Mac for travel development?

A local MacBook is better for long offline periods, physical device testing, and work that cannot tolerate network dependence. A remote Mac is better when you need a stable macOS environment from several lightweight devices. If your work includes production access or frequent border and network changes, use both: remote Mac for the main environment and local hardware for emergency work.

First week: measure delivery, not just connectivity

During the first week, record facts that affect delivery:

  • Which networks allowed you to connect.
  • Whether SSH and screen sharing both worked.
  • How long reconnection and state verification took.
  • Whether authentication or permission prompts blocked progress.
  • How much storage the project and dependencies consumed.
  • Which tasks completed with reviewable evidence.
  • Which tasks still required a local Mac.
  • Whether a Claude Code update changed your installation or workflow.

Do not convert one successful café session into a permanent architecture decision. A cloud Mac workstation is suitable when it survives several realistic transitions and your project remains reviewable after each one.

Schedule maintenance around the project rather than around vague “keep it updated” advice. Review credentials, repository backups, dependency updates, access users, and recovery notes at a fixed interval that matches your project risk. Before a long trip, perform one full restore or clean checkout exercise.

The digital nomad backup and recovery workflow should be treated as a separate planning concern from remote access. Remote execution protects continuity only if your source code, credentials procedure, and recovery instructions are also recoverable.

Choose the final workflow with clear conditions

Use this decision branch after the rehearsal:

  • If your project needs macOS, you switch devices often, and your travel route normally has usable internet, choose a cloud-first workflow.
  • If you work offline for extended periods, need physical interfaces, or depend on local hardware, keep a full local environment.
  • If the project is sensitive, high-impact, or difficult to reconstruct, choose dual-track operation.
  • If you cannot verify task state after a simulated disconnection, do not migrate the project yet. Fix the recovery path first.
  • If every task requires manual approval while you are away from a reliable connection, reduce task scope or keep that work local.
  • If the environment is stable but your travel period is short, test a short rental period before choosing a longer commitment.

The right setup is not the one with the fewest devices. It is the one that lets you prove what happened after a network change.

When a cloud Mac is the better travel compromise

A local MacBook gives you direct access, offline capability, and fewer remote layers. It also creates a single physical dependency. Loss, damage, battery limits, local configuration drift, and the need to carry the machine through every transfer can all stop work at once.

A remote Mac avoids carrying the primary macOS environment, but it introduces network dependency, access-control work, and a need to rehearse recovery. For a digital nomad running Claude Code across cafés and coworking spaces, that trade can be sensible when the project is online by nature and the remote host has been tested.

If you keep rebuilding the environment after switching devices, or if your lightweight device cannot safely retain long Claude Code tasks, rent a cloud Mac from MACCOME and run one real project through the disconnection test. Check the current MACCOME cloud Mac options, then choose weekly, monthly, or quarterly access only after matching the period to your travel schedule and project delivery window.

Keep the local device for offline emergencies. Keep the cloud host for the main environment. That cloud-execution, local-access, dual-track model is the safer default for Claude Code remote development in 2026.