Codex Remote Mac 2026: Long-Task Setup Guide

Before deployment: choose the execution host

The first decision is not how to pair the phone. It is where the task should run.

The mobile app can display task state, approvals, screenshots, terminal output, diffs, and test results from the connected environment. It does not move the repository or local execution context onto the phone. Files, credentials, installed tools, and local configuration remain on the machine running Codex. (openai.com)

That distinction creates three practical deployment choices:

A primary Mac is acceptable when the task can stop without material loss and the repository contains no sensitive production material. A dedicated host is the better default when the Mac must remain powered and available while its owner is away. A cloud Mac deserves consideration when the environment must be handed to another person, recreated quickly, or accessed from different locations.

The desktop application requirement is also a gate. The current macOS app documentation lists macOS 14 and either Apple Silicon from M1 onward or an Intel processor as the supported baseline for the new app. Check the current requirement before purchasing or renting a host, because remote availability and account rollout can change independently of the operating-system baseline. (help.openai.com)

For a temporary project, a dedicated cloud Mac environment can be evaluated without changing the developer’s personal workstation. The important question is not whether the host is physically nearby. It is whether the host remains online, has the required tools, and can be reset or revoked when the task ends.

The first 30 minutes: update, sign in, and pair

Remote access should be treated as a controlled connection between four layers:

1. The phone and its ChatGPT mobile app.
2. The desktop application running on the Mac.
3. The local repository and development tools.
4. The account or workspace policy that determines whether the feature is available.

Codex is not selected as a normal mobile or web workspace. Supported desktop Codex chats are reached through the Remote tab in the mobile app, and those chats may remain separate from ordinary web and mobile history. Account, plan, region, and workspace rollout can affect what appears in the interface. Do not assume that every account exposes the same controls on the same day. (help.openai.com)

Follow this sequence:

1. Confirm the host

On the Mac, record:

sw_vers
uname -m

A typical output may look like this:

ProductName:    macOS
ProductVersion: 14.x
BuildVersion:   23xxxx
arm64

The output is an inventory record, not proof that every Remote feature is enabled. Confirm that the desktop app is current, the Mac is signed in, and the correct workspace is selected.

2. Update both endpoints

Update the desktop application on the Mac and the ChatGPT mobile app on the phone. Avoid pairing a freshly updated phone with an outdated desktop host during the first test. If the interface differs between devices, check the account and workspace before changing system settings.

The official rollout describes mobile access as a preview capability and states that support is being expanded over time. Treat an unavailable Remote tab as a rollout or policy issue first, not as evidence that the Mac is misconfigured. (openai.com)

3. Use the same account and workspace

The phone and host must point to the intended account context. A personal account paired with a team workspace, or a personal desktop session paired with a company mobile account, can produce confusingly incomplete project lists and approval behavior.

Before pairing, write down:

Account:
Workspace:
Host label:
Repository:
Expected operator:

This simple record helps when a team has multiple Macs or when a connection must later be revoked.

4. Start pairing from the Mac

Open the desktop app on the Mac and use its connection flow. Scan the displayed QR code or complete the verification method offered by the current app version. Then open the Remote tab in the mobile app and confirm that the expected host and supported Codex chat appear.

Do not send a production task at this stage. The first successful connection proves only that the control path exists. It does not prove that the repository is correct, that the host will stay awake, or that every approval action works from the phone.

5. Run a read-only test

Start with a task that lists the project structure and reports the current branch without editing files:

Inspect the repository root, report the current branch, and identify the test command.
Do not edit files, install packages, access the network, or create commits.

Expected evidence should include the correct repository path, branch name, and test command. If the path is wrong, stop immediately and fix the local project selection before granting broader access.

The first task: restrict the project and execution boundary

A long-running agent should not begin in the main branch of a sensitive repository. Use a disposable branch or worktree and keep the task reversible.

A safe first layout might be:

~/CodexWork/
├── task-repo/
├── task-repo-worktree/
└── logs/

Create a separate worktree when parallel work is expected:

git worktree add ../task-repo-worktree -b codex/remote-smoke-test
git status --short
git branch --show-current

The exact commands depend on the repository and team workflow, but the control principle is stable: verify the directory and branch before allowing file writes.

Separate permissions into categories rather than treating “Codex access” as one switch:

• File access: Which directory can be read or modified?
• Shell access: Which commands can run without approval?
• Network access: Can dependencies, APIs, or remote services be reached?
• Computer Use: Can the agent interact with graphical applications?
• External tools: Which plugins, MCP servers, or integrations are enabled?
• Git actions: Can the agent commit, push, create a pull request, or change branches?

The first task should normally allow ordinary file inspection and selected tests while keeping destructive shell commands, credential access, production deployment, and external write actions behind human approval. OpenAI’s current guidance for connected apps and plugins also recommends starting read-only where possible, limiting access to approved repositories or folders, and reviewing write actions before rollout. (help.openai.com)

Keeping long tasks alive: power, sleep, and recovery

A long task fails for reasons that have little to do with model quality. Common interruptions include:

1. The Mac enters sleep.
2. A laptop lid is closed.
3. The network changes or drops.
4. The desktop application stops running.
5. A system update or restart claims the host.
6. A personal user changes the project or approval state.
7. The task waits indefinitely for a decision that nobody sees.

The official remote-access description says the work continues on the connected machine, while the mobile app receives live state from that environment. That means the Mac must remain available and the desktop application must continue operating. (openai.com)

On a dedicated desktop Mac, configure power and display behavior before starting an unattended task. On a laptop, connect power and treat a closed lid as an unverified state unless the current documentation and a controlled test confirm otherwise.

For a temporary terminal session, a basic macOS keep-awake command is:

caffeinate -dimsu

Stop it with Control-C when the task ends. This does not repair a broken network, keep the desktop application open after a crash, or guarantee that every remote-control feature survives system state changes. Apple’s support documentation separately distinguishes display-off behavior, automatic sleep, network wake settings, and background processes, so these settings should be checked individually. (support.apple.com)

Test the following states with a harmless repository:

• Display on, user logged in.
• Display locked, user logged in.
• Display off while connected to power.
• Temporary network interruption.
• Desktop app restart.
• Manual task cancellation.
• Phone disconnected and reconnected.

The behavior of lock screen, closed lid, Computer Use, and task continuation should be reported as an observed result for the tested app and operating-system versions. It should not be generalized into a permanent product guarantee.

Queue and Steer need different handling

Use Queue when the current direction is correct and the next task can wait. Examples include asking for a test report after the current implementation or requesting a diff summary before review.

Use Steer only when the current direction is clearly wrong. Examples include a mistaken repository path, an incorrect framework assumption, or an unsafe attempt to modify production configuration.

Overusing Steer can create competing instructions while the agent is already changing files. If the task is still correctly scoped, Queue is less disruptive. If the agent has entered the wrong branch or begun an unsafe action, stop the task and correct the boundary before adding more instructions.

Day one: protect secrets and add Codex Hooks carefully

Long tasks often expose a problem that short tasks hide: credentials remain available for too long.

Move API keys, signing materials, cloud tokens, database passwords, and production configuration out of ordinary project files. Use a dedicated local account or project directory where practical. Prefer short-lived, least-privilege credentials and revoke them when the task or contract ends.

A basic secret inventory should answer:

Which credentials exist?
Which repository can reach them?
Which command can use them?
Who approved access?
When will they be revoked?

Codex Hooks can support secret scanning, validators, logging, and repository-specific workflow controls. The official announcement says Hooks can scan prompts for secrets, run validators, log conversations, create memories, and customize behavior for repositories or directories. (openai.com)

However, Hooks are executable local workflow components. An unmanaged Hook should be treated as code that can run during the Codex lifecycle, not as a harmless configuration label. Current Codex documentation describes trust state for unmanaged Hooks and supports managed-only enforcement for administrators. (github.com)

A review process should include:

1. Read the Hook source.
2. Confirm its command path and interpreter.
3. Check whether it reads prompts, tool inputs, environment variables, or files.
4. Confirm where logs are written.
5. Test failure behavior.
6. Approve only the repository and account that need it.
7. Remove or disable it when the project ends.

Useful Hook roles include blocking a command that targets a production directory, rejecting prompts that contain a known secret pattern, running a fast validation script before a sensitive tool call, and recording task completion events. Hooks should complement permission controls, not replace them.

First-week acceptance: decide whether to stay local

A successful pairing is not a successful deployment. The first week should measure whether the environment remains dependable when the owner is away.

Use this acceptance checklist:

• [ ] The host remains powered and reachable during the intended work window.
• [ ] The desktop application stays open after display lock.
• [ ] A low-risk task can be reviewed from the mobile Remote tab.
• [ ] Approval requests appear on the phone and are understandable without a desktop.
• [ ] The correct repository, branch, and worktree are selected.
• [ ] The task can be stopped without leaving an unknown process running.
• [ ] A temporary network interruption has a documented recovery procedure.
• [ ] Secrets are outside ordinary project files.
• [ ] Production commands require manual approval.
• [ ] Unmanaged Codex Hooks have been inspected and trusted deliberately.
• [ ] SSH keys, account sessions, and device connections can be revoked.
• [ ] Another authorized operator can understand the host state from the written record.

Track the following observations rather than relying on impressions:

Connection failures:
Task interruptions:
Approval wait time:
Unexpected commands:
Environment contamination:
Recovery time:

If the primary Mac must stay powered every night, personal work competes with the agent, or several projects need different toolchains, the local setup is already showing the limits of a shared workstation. If the team needs handoff, reproducible resets, regional delivery, or separate operator permissions, a dedicated cloud Mac becomes easier to govern.

A regional NodeMini cloud Mac option can be assessed after the local acceptance test, not before. The correct comparison is based on recovery and control requirements, not only on raw machine specifications. For teams that need to document access boundaries first, the remote Mac SSH and key configuration path is a useful next step before moving long-running work off a personal machine.

The final decision: primary Mac, dedicated host, or cloud Mac

Choose the primary Mac when all of these conditions are true:

• Tasks are short or easily restartable.
• The repository is low risk.
• One person owns the environment.
• The Mac does not need to serve personal work at the same time.
• Manual approval is available during execution.

Choose a dedicated Mac when:

• Long tasks must run without competing with daily work.
• Personal files and AI-agent repositories should be separated.
• One developer owns the environment but needs it available remotely.
• The team accepts responsibility for updates, power, network, and recovery.

Choose a managed cloud Mac when:

• Multiple people need controlled access.
• The environment must be reset or handed off.
• Several projects require separate images or directories.
• The host must be available without depending on a personal laptop.
• The team needs a documented delivery and acceptance process.

For short experiments, the primary Mac is usually the least disruptive choice. For sustained Codex Remote use, the dedicated host provides a cleaner boundary. For team operations, the cloud option is often easier to revoke, replace, and standardize.

A personal Mac has three real weaknesses in this role: it can be interrupted by sleep or updates, it mixes private files with agent work, and its recovery process depends on one person being available. Renting a NodeMini Mac is a better fit when the objective is a temporary, isolated, remotely reachable environment that can be handed off or retired after the project. It is not automatically the right answer for permanent heavy workloads, physical-interface testing, or a developer who already has a well-maintained always-on host. The first-week acceptance results should determine whether the extra separation justifies the move.

Frequently asked questions

Can Codex Remote keep working after the Mac is locked?

Locking the display is not the same as putting the Mac to sleep or closing a laptop lid. Remote access depends on the host remaining online, the desktop application continuing to run, and the current supported behavior of the operating system and app. Treat lock-screen behavior as a test item, not a guaranteed capability. Verify it with a low-risk repository before trusting an unattended production task.

How do I connect my phone to a Mac that is running Codex?

Install the current ChatGPT mobile app and the current Codex-capable desktop app on the Mac, sign in with the same account and workspace, then start the connection from the desktop host. Use the pairing flow shown by the app and complete any requested verification. The mobile Remote tab controls supported desktop Codex chats; it does not turn the phone into the execution host.

Should Codex Remote run on my main Mac or a dedicated Mac?

Use the main Mac for short, low-risk tasks when interruption is acceptable. Choose a dedicated Mac when work must stay online, several repositories compete for the same environment, or credentials need isolation from personal files. A managed cloud Mac becomes more suitable when the team needs resettable environments, handoff, centralized access, or predictable recovery.

How can I restrict Codex Remote access to selected repositories, commands, and secrets?

Start with a separate project directory and a low-risk branch or worktree. Grant only the files, tools, and network access needed for the task. Keep production credentials outside ordinary project files, use least-privilege accounts, require approval for destructive commands, and review every unmanaged Codex Hook before enabling it. Add logging and a documented revoke process before running unattended work.