A shared remote Mac lets Codex CLI start, edit files, and run builds, but that does not prove the setup is safe for multiple repositories.
This week, do not run Codex CLI in a shared high-privilege account. Use a dedicated low-privilege account, repository-specific workspaces, minimal sandbox and approval settings, then validate files, network, credentials, Xcode actions, and recovery before launch. If isolation cannot be proven, fall back to a single-repository temporary node or a dual-track workflow.
This guide is for you if you operate a remote Mac for agent-assisted development, DevOps automation, or Apple-platform CI.
It is also for platform and security owners who need evidence about source-code boundaries, SSH agents, Keychain access, signing identities, external tools, and restart behavior.
Start with the boundary, not the successful launch
The first acceptance question is not whether Codex CLI can open a repository. It is whether the process can cross a boundary that your operating model depends on.
Codex’s local sandbox, approval policy, macOS account permissions, SSH agent, Keychain, and external execution tools are separate controls. A restrictive setting in one layer does not repair an overly broad setting in another. OpenAI’s sandbox and approval documentation describes how command execution is constrained, while the permissions documentation explains how approval behavior affects command execution.
Use this initial decision rule:
- If Codex CLI runs under a dedicated non-administrator account, each repository has an isolated workspace, credentials are temporary or read-only, and forbidden-path tests fail as expected, choose controlled multi-repository operation.
- If the account is separate but workspaces, caches, or external tools remain shared, choose single-repository rotation.
- If Codex CLI can reach production signing material, unrelated source trees, or unrestricted external executors, rebuild the node or suspend agent execution.
- If the evidence is incomplete, choose a limited trial with non-production repositories. Do not turn missing evidence into an approval.
The following table defines the minimum evidence package. It is not a substitute for testing; it tells you what each test must produce.
| Metric | Test object | Evidence to retain | Pass condition | Stop condition |
|---|---|---|---|---|
| File boundary | Workspace, parent paths, Git metadata, temporary folders | Before-and-after tree, file diff, process log | Only the assigned workspace changes | Unrelated repository is read or modified |
| Network boundary | Model traffic, dependency hosts, Git remotes, APIs, external tools | Requested host, decision, approval record | Only documented destinations are reachable | Unknown destination succeeds without review |
| Credential boundary | Environment, SSH agent, Keychain, signing identities | Credential visibility result and account snapshot | Only task-specific credentials are visible | Production or unrelated credentials appear |
| Execution boundary | Shell commands, scripts, Xcode tools, MCP or proxies | Command record and tool path | Each executor follows the same policy | A tool bypasses the local control |
| Recovery boundary | Interrupt, logout, SSH loss, reboot, repository switch | Process list, cleanup record, restart result | No unexplained residue remains | Orphaned process, token, socket, or file remains |
The Codex configuration source is useful when mapping permission fields to the version you are testing, but do not copy a configuration key from an old example without checking the current configuration source.
Compare workspace isolation with account isolation
A repository folder is not the same thing as a security boundary. A process may still see parent directories, shared temporary paths, Git metadata, build caches, SSH sockets, or scripts that reference another workspace.
Run the file test with at least two non-production repositories. Use placeholders such as <REPO_A>, <REPO_B>, <WORKSPACE_A>, and <WORKSPACE_B>. Do not place real tokens, certificates, Team IDs, or production paths in the test instructions.
| Operating model | What it isolates | What it leaves exposed | Decision |
|---|---|---|---|
| Shared administrator account with separate folders | Basic project organization | Account files, credentials, caches, system services, broad write access | Reject for unattended agent work |
| Dedicated account with separate workspaces | Account boundary plus project paths | Shared caches, temporary folders, forwarded agents, external tools | Accept only after negative tests |
| Dedicated account and isolated node per repository | Account, workspace, and lifecycle boundary | Provider, network, and toolchain controls still require testing | Strongest default for sensitive work |
| Single node with repository rotation | Limits simultaneous exposure | Residual processes, files, caches, and credentials can leak between jobs | Use only with verified cleanup |
File acceptance sequence
Milestone one: inventory. Record the account name, home directory, workspace path, repository remote, Git configuration, temporary directory, build cache locations, and active processes before the task starts.
Milestone two: read test. From <WORKSPACE_A>, attempt an approved read. Then attempt to inspect <WORKSPACE_B>, its parent directory, and a controlled decoy file. A failed access is evidence only if the failure is logged and repeatable.
Milestone three: write test. Create a harmless marker inside <WORKSPACE_A>. Attempt a marker write inside <WORKSPACE_B>, a parent path, and a shared temporary location. The expected result is that only the assigned workspace changes.
Milestone four: Git test. Check whether the agent can inspect another repository’s .git metadata, remotes, hooks, worktrees, or credentials. A workspace rule that protects source files but exposes Git metadata is incomplete.
Milestone five: residue test. Interrupt the task, switch from <REPO_A> to <REPO_B>, and inspect untracked files, generated scripts, logs, sockets, and temporary artifacts. Record every leftover item before cleanup.
The stop condition is simple: if a forbidden read or write succeeds, do not try to correct the behavior with a stronger prompt. Prompt instructions are not a replacement for system permissions.
Separate network access from external execution
Teams often treat network access as one switch. It is not. Codex CLI may need model communication, dependency downloads, Git operations, service APIs, or tool execution, and each path has a different risk.
The official Codex network material distinguishes network behavior from other command controls. Review the Codex network reference against the exact version and deployment mode under test.
Use this sequence:
- Begin with the most restrictive documented network mode.
- Record the destination required for model communication.
- Test dependency retrieval separately from Git fetch and push.
- Test API calls with a controlled endpoint.
- Test external tools and MCP executors as separate principals.
- Repeat the same actions when approval is required and when approval is denied.
- Preserve the requested host, command, approval result, and final network result.
Do not infer that disabling approval automatically enables network access. Approval controls whether an action can proceed under a policy; it does not prove that the network path exists or that the destination is allowed.
| Network or tool path | Test | Expected evidence | Reject when |
|---|---|---|---|
| Model communication | Start a controlled task under the approved policy | Connection result and policy state | Traffic works outside the documented policy |
| Git remote | Fetch from <GIT_HOST> using a test repository |
Host, credential type, fetch result | Push or access to an unrelated remote succeeds |
| Dependency source | Resolve a pinned dependency | Host list and lockfile result | Arbitrary domains are reachable |
| Service API | Call <TEST_API_ENDPOINT> with a temporary token |
Request record and response scope | Production API is reachable |
| MCP or tool proxy | Run a harmless external-tool test | Executor identity and command record | The executor bypasses local sandbox or approval |
A community report can reveal a boundary worth reproducing, but it is not proof of a general vulnerability. Treat GitHub Issue 32919 as a review lead only. Reproduce the report under your exact Codex CLI, macOS, account, and tool configuration before changing the risk rating.
Compare credential tiers before allowing Xcode actions
The most dangerous mistake is to test only whether a build succeeds. A successful build may hide access to signing identities, Keychain items, SSH agents, environment variables, or upload credentials.
Use three credential profiles:
| Profile | Allowed material | Test purpose | Approval outcome |
|---|---|---|---|
| Empty profile | No SSH agent, no signing identity, no upload token | Establish the unauthenticated baseline | Read, build, and local test only |
| Read-only profile | Read-only repository or dependency access | Confirm required source and package operations | No push, release, or credential mutation |
| Temporary profile | Short-lived test token and non-production signing assets | Validate the complete controlled workflow | Revoke after the test and confirm failure |
First inspect the system account used by the Codex CLI process. Then inspect environment variables, SSH agent forwarding, login Keychain access, Xcode signing identities, provisioning material, and upload credentials.
Apple’s Keychain Access guidance explains that access authorization depends on the item and the requesting application. That means “the file is not in the repository” does not prove that the secret is unavailable.
For each profile, capture:
- Whether the process can list or use the SSH agent.
- Whether it can read an unrelated private key.
- Whether it can access a controlled Keychain item.
- Whether Xcode can select a signing identity.
- Whether
xcodebuildcan compile without signing. - Whether signing works with a temporary identity.
- Whether upload actions remain unavailable.
- Whether revocation causes the next attempt to fail.
The hard stop is exposure of a production signing private key, production upload token, or unrelated SSH credential. Do not place such material in a default agent session to make a test more realistic.
Validate Xcode execution without confusing capability with reproducibility
Codex CLI may be able to invoke xcodebuild, simulator commands, scripts, and package tools. That proves execution capability, not that the pipeline is safe or repeatable.
Use a disposable test project with a controlled dependency set. Run a local compile, a test target, a simulator action, and a signing action with non-production assets. Separate the results. A build that passes only because a previous repository left derived data or a Keychain authorization behind is not a clean pass.
Check these boundaries:
- Source workspace and generated files.
- Derived data and module caches.
- Simulator state and device data.
- Local scripts and executable permissions.
- Ports and background services.
- Package manager caches.
- Logs containing source paths or tokens.
- Signing and archive output.
- Upload or release commands.
For concurrent work, use separate workspaces and deliberately overlapping task windows. Look for changes to the wrong checkout, shared derived data, port collisions, stale simulator state, mixed logs, and credentials inherited by the second task.
Choose the narrowest mode supported by the evidence:
- If builds are isolated but concurrent caches collide, use single-repository rotation.
- If concurrent builds remain clean but signing is not isolated, allow review and test jobs only.
- If Xcode requires a shared state that cannot be reset reliably, use a dedicated node pool.
- If a script can reach production services or release assets, remove that action from the agent workflow.
For teams evaluating a longer-lived Apple build node, compare this acceptance work with a remote Mac CI/CD runner security model. The goal is not to assume that a hosted Mac is secure; it is to decide which controls must be demonstrated before the node handles real repositories.
Use recovery as the final release gate
A node that is safe during a clean run may become unsafe after interruption. Test the states that operators actually encounter: an SSH disconnect, a cancelled Codex CLI task, a process crash, a repository switch, a logout, and a Mac restart.
At each stage, record:
- Active Codex CLI and child processes.
- Open files and sockets linked to the task.
- Temporary files and generated scripts.
- Workspace changes and untracked files.
- Build artifacts, logs, and derived data.
- SSH agent state and temporary credentials.
- Keychain authorization state.
- Simulator and background service state.
- The first task after restart.
A recovery pass requires more than a successful reboot. The next task must start with the expected account, workspace, network policy, and credential profile. If a previous task leaves an orphan process, token, socket, or authorization that changes the next task’s access, stop using repository rotation until the lifecycle is redesigned.
Acceptance decisions for this week
Use these conditions to turn evidence into an operating decision:
- Choose controlled multi-repository operation if all file, network, credential, Xcode, cleanup, and restart tests pass under a dedicated low-privilege account.
- Choose single-repository rotation if the account and file boundary pass, but shared caches, concurrent execution, or cleanup remain uncertain.
- Choose an independent node per repository group if Xcode signing, simulator state, or long-running services cannot be reliably reset.
- Choose review-only agent access if the agent can inspect code safely but cannot be trusted with write, build, signing, or external execution.
- Rebuild or postpone if production credentials, unrelated repositories, unrestricted network paths, or untracked residue remain accessible.
If you need a temporary environment for non-production validation, review the available remote Mac access options only after defining the isolation requirements. A rental node can shorten the test cycle, but it does not remove your responsibility to verify account permissions, workspace boundaries, credentials, and recovery.
FAQ
Is it safe to run Codex CLI across several repositories on a remote Mac?
Only after the node proves account and workspace isolation. Do not place Codex CLI in a shared administrator account. Use a dedicated low-privilege system account, separate workspaces, restricted credentials, and an approval policy that matches the task. If cross-repository reads or writes remain possible, use a single-repository temporary node instead.
How can I restrict Codex CLI to the current repository?
Start with a repository-specific workspace and a dedicated system account, then test both allowed and forbidden paths. Check Git metadata, parent directories, temporary folders, build outputs, and shared caches. A prompt telling the agent to stay inside one folder is not a system boundary. Stop the rollout if the process can modify an unrelated repository.
Can Codex CLI on a remote Mac access SSH keys or Keychain items?
Potentially, depending on the account, agent forwarding, environment, Keychain permissions, and task tooling. Test with no credential, read-only credential, and temporary credential profiles. Inspect SSH agent exposure, environment variables, login Keychain access, signing identities, and upload credentials. Never expose a production signing private key to a default agent session.
How should I clean up multi-repository Codex CLI jobs?
Treat cleanup as a tested control, not a manual habit. Interrupt the task, disconnect SSH, exit Codex CLI, switch repositories, and restart the Mac. Then verify that processes, temporary files, logs, worktrees, sockets, credentials, and build artifacts are removed or accounted for. Preserve the resulting evidence before reusing the node.
What should I test before putting Codex CLI on a remote Mac into production?
Test file isolation, network rules, account permissions, SSH and Keychain visibility, Xcode build behavior, external tool paths, concurrent workspace use, cleanup, and restart recovery. Record the attempted action, observed result, evidence, and stop condition for each test. Approve only the narrowest operating mode that the evidence supports.
A shared remote Mac is attractive because it stays online, but shared high-privilege accounts, mixed workspaces, persistent credentials, and weak cleanup create failure modes that a prompt cannot control. If you need temporary Codex CLI testing, use a non-production repository and validate the node before granting broader access. For longer-lived multi-repository work, compare single-node rotation with independent nodes or dual-track CI, then proceed only when the evidence supports the chosen model.