Where Should Mac Builds Go After VS Code 1.138 Agent Creates a PR? 2026

A successful PR created by the VS Code 1.138 Agent should stay in the Agent Host, while delivery evidence belongs in independent CI and a separate Mac build layer.

Use a shared host only for low-risk prototypes. For Xcode, signing, Apple platform regression, or unattended release work, move execution to an isolated cloud Mac.

Who should read this: iOS and macOS teams deciding where an Agent-created PR should run Xcode. Platform engineers separating Agent Host, CI Runner, and remote execution responsibilities. AI startups balancing infrastructure cost against workspace contamination and build queues.

The operating boundary

The key mistake is treating one successful action as proof of the entire delivery chain. VS Code 1.138 can support reviewing and creating a Pull Request from an Agent Host session, including draft status and available merge options, according to the VS Code 1.138 release notes. That confirms PR creation. It does not confirm that tests passed, branch rules were satisfied, or an Apple build is releasable.

Keep these states separate:

• PR created: the Agent produced commits and opened a Pull Request.
• Checks passed: the required CI jobs completed against the intended commit and environment.
• Release-ready: the code passed the required Apple platform validation, review, signing controls, and release approvals.

The Agent Host is a good place to edit files, inspect repository context, run controlled development commands, and initiate a PR. It is a poor place to act as the final authority for its own work. The Agent Host architecture documentation describes the host as the environment that manages agent sessions and their execution context. That role should not be confused with an independent verification system.

Your evidence package should include the commit identifier, changed-file summary, test commands, test output, runner identity, toolchain details, and artifact references. A green interface indicator without those records is not enough for a high-risk repository.

Scenario matrix for environment choice

Use the table below before changing your infrastructure. It separates code type from delivery consequence.

This is the default three-layer design: Agent Host for modification and PR creation, deterministic CI for general checks, and an independent cloud Mac for Apple delivery evidence.

Pure web and cross-platform work

For a web service, command-line tool, shared library, or containerized application, adding a Mac for every PR usually creates cost and queue overhead without adding useful evidence. Keep the Agent Host responsible for the change and let GitHub Actions or another deterministic runner execute linting, unit tests, dependency checks, and container builds.

The important condition is reproducibility. A test should run from a clean checkout, use a declared toolchain, and publish its results independently of the Agent session. GitHub Actions workflow artifacts can preserve files produced by a workflow, as explained in the official artifact documentation. Store test reports, coverage output, generated metadata, and packaged samples there when they are needed for review.

You can continue using a general-purpose Runner without adding a Mac when all of these conditions hold:

• The changed code does not call Xcode, Apple SDKs, Simulator services, or Apple-only frameworks.
• The required checks run in a clean and repeatable environment.
• The result is tied to the exact PR commit.
• The workflow does not require a signing key, provisioning profile, device connection, or protected release credential.
• A failed check can be reproduced without reconnecting to the Agent Host session.

Do not describe the PR as ready merely because the Agent created it. Do not describe it as safe to release because a single portable test passed. The repository policy still determines what is required before merge.

CI after a VS Code Agent PR

A VS Code Agent Host-created PR still needs CI when the repository uses automated checks, even if the Agent ran similar commands locally. The reason is not distrust of the model alone. It is the difference between an interactive session and an independent execution record.

The CI system should answer questions the Agent session cannot answer by itself:

• Did the check run against the pushed commit rather than an uncommitted workspace?
• Did the workflow use the expected dependency lockfile and toolchain?
• Did an independent identity report the status?
• Were logs and artifacts retained for later review?
• Did branch protection require this exact check before merge?

The GitHub workflow log documentation explains how workflow execution records can be inspected. Use those records as the source of truth instead of copying terminal output from the Agent conversation.

A practical handoff has five actions:

• Push the Agent-created commit and record its hash.
• Trigger the normal PR workflow.
• Confirm that required checks reference the same commit.
• Save logs and artifacts outside the Agent workspace.
• Require a human or approved review path before merge when repository policy demands it.

This also prevents a subtle failure: an Agent may fix the working tree after a failed local test, then create a PR from a different state than the one you reviewed. The commit and workflow record close that gap.

Xcode and Apple platform work

Xcode tasks change the environment decision. If the PR touches an iOS or macOS target, Apple framework usage, project settings, Simulator behavior, or signing configuration, a generic container or Linux Runner cannot replace a real macOS validation layer.

Apple’s documentation distinguishes testing on simulated and physical devices in its Xcode device testing guidance. The practical consequence is simple: an Agent can prepare the change, but the Apple-specific result must be produced by an environment that actually has the required macOS and Xcode toolchain.

Running Xcode on the same Mac as the Agent Host can work for a low-risk prototype, but it creates three material risks:

• Workspace contamination: dependency caches, derived data, uncommitted files, and background processes can affect later runs.
• Weak reproduction: another engineer may not be able to reconstruct the exact session state after an interruption.
• Task contention: a long build or Simulator session can consume CPU, disk, or interactive access while the Agent is trying to modify code.

An independent cloud Mac gives you a cleaner boundary. The Agent submits a commit or PR reference. The Mac worker checks out that reference, runs the declared Xcode commands, stores logs and build products, and reports status back to CI. Signing and release credentials remain unavailable to the code-generation host.

The GitHub runner selection documentation can help you decide when a job needs a specific runner label or environment. If you operate your own Mac workers, also review the self-hosted Runner security guidance before allowing untrusted or model-generated code to execute on them.

Agent Host and GitHub Actions Runner placement

An Agent Host and a GitHub Actions Runner can use the same Mac, but “can” is not the same as “should.” Shared placement is acceptable only when the repository is low risk, the workspace is disposable, no signing credentials are present, and the build cannot block other work.

Separate them when any of the following applies:

• The Mac stores certificates, provisioning profiles, notarization credentials, or release tokens.
• The Agent can execute arbitrary scripts from an untrusted PR.
• The Xcode job is long enough to delay interactive development.
• Multiple repositories share the host and leave mutable caches behind.
• You need an audit trail that proves which identity performed code changes and which identity produced build evidence.
• The task must continue after the client disconnects or the Agent session ends.

The cleanest design uses an Agent Host for repository changes, a general CI Runner for portable checks, and a Mac Runner for Apple-specific jobs. The GitHub branch policy should accept only the expected status checks. It should not accept a manually reported success from the Agent conversation.

Protected branches and high-risk repositories

Creating a PR does not bypass branch protection, required reviews, required status checks, or merge queue rules. GitHub’s protected branch documentation describes the controls that can remain in force after a PR is opened.

Before enabling an Agent workflow, verify:

• Which repository identity the Agent uses.
• Whether that identity can push to the intended branch.
• Whether it can create draft or ready-for-review PRs.
• Which workflow identity reports required checks.
• Whether the Agent can approve, dismiss reviews, or influence merge status.
• Whether merge queue behavior is enforced after all checks pass.

Keep the code-changing identity separate from the identity that attests to build results. This prevents the same actor from modifying a workflow and then presenting its own output as independent evidence.

For a high-risk repository, start with draft PRs, independent checks, protected branch rules, and no permission to bypass policy. The release process should stop when the expected check is missing, the commit changes after validation, or the Mac artifact cannot be tied to the reviewed source.

Remote hosts and long-running tasks

A remote Agent Host or cloud Mac does not automatically make a task recoverable. You need to separate three kinds of state:

• Code state: commits, branches, worktrees, dependency locks, and uncommitted changes.
• Task state: prompts, execution status, retry history, and the last completed command.
• Build state: logs, derived outputs, test reports, archives, and signing results.

Do not keep the only copy of any of these inside an interactive session. Push commits to the repository, preserve workflow evidence as artifacts, and record build outputs in a controlled storage location. If a client disconnects, verify whether the process continues, whether the workspace remains locked, and whether another worker can safely take over.

A recovery test should deliberately cover:

• Client disconnect and reconnect.
• Agent interruption during dependency installation.
• Xcode failure after compilation but before packaging.
• Mac worker termination during a long test.
• Reassignment of the same PR to another worker.
• Cleanup of abandoned workspaces.

The stopping rule is strict: if you cannot identify the last verified commit, the last completed command, and the integrity of the workspace, do not resume an in-place build. Start from a clean checkout and rerun the required checks.

Long Xcode work belongs in a dedicated queue. Do not let it occupy the same host that generates code interactively. The queue should record waiting time, execution time, retry time, and approval time. Those measurements tell you whether the real problem is insufficient Mac capacity or inefficient scheduling.

Parallel Agents and Mac build peaks

Multiple Agents can share repository context while still creating separate PRs, but parallel PRs move the bottleneck. Model generation may finish quickly while dependency installation, test scheduling, Simulator availability, and Mac capacity become the limiting factors.

Do not assign one Mac to every Agent session by default. First classify the workload:

• Portable checks can share general Runners when they are isolated and reproducible.
• Short Apple checks can use a shared Mac pool if each job starts from a clean workspace.
• Long Xcode builds should use a queue or dedicated workers.
• Signing and release jobs should use a protected environment with narrow access.
• Burst demand may justify temporary elastic Mac capacity rather than permanent allocation.

Track these values separately:

• Queue wait time.
• Actual build execution time.
• Failure and retry time.
• Human approval time.
• Workspace cleanup time.
• Percentage of jobs requiring a second Mac attempt.

If execution time dominates, increase or rebalance Mac capacity. If queue time dominates only during short peaks, improve scheduling or add temporary capacity. If retry time dominates, fix workspace isolation and dependency caching before buying more machines.

The three-layer decision table

Use this table to choose the next infrastructure action rather than making a broad platform change.

This table gives you three operational outcomes: keep the current setup, split the build layer, or add elastic Mac capacity. Choose based on failure evidence, not on the number of Agent sessions.

Implementation sequence

Follow this sequence before moving production work onto a shared or rented Mac:

• Map every command run by the Agent, CI Runner, Mac worker, and release system.
• Label each command as code modification, deterministic check, Apple validation, signing, or publishing.
• Record the commit hash at PR creation and again at each build start.
• Move portable checks into GitHub Actions or your existing deterministic CI.
• Create a Mac job that starts from a clean checkout and publishes logs and artifacts.
• Remove signing and release credentials from the Agent Host.
• Test interruption, reconnect, retry, and workspace takeover.
• Add branch protection requirements for the independent checks.
• Measure queue and execution behavior during normal and peak workloads.
• Decide whether shared capacity, a dedicated pool, or elastic capacity matches the evidence.

For teams evaluating remote capacity, the kvmsync blog is the natural place to continue with related infrastructure guidance. If the current Mac is already overloaded, review cloud Mac availability and pricing only after you have separated build demand from Agent demand.

The practical recommendation

If your current setup lets the Agent modify code, run Xcode, access signing credentials, and report its own success from one Mac, it has too many responsibilities. The immediate correction is not necessarily a large infrastructure purchase. First separate the evidence path: independent CI for portable checks and an isolated Mac job for Apple validation.

The current shared approach has real weaknesses. A long Xcode task can block code generation, mutable caches can make failures difficult to reproduce, and shared credentials increase the impact of an unsafe command. A cloud Mac layer gives you cleaner workspace boundaries, controlled capacity, and a repeatable place for Xcode execution without forcing every Agent session to own a physical machine.

Mark your present workflow against the decision table. If Xcode still runs on the Agent Host, continue with a cloud Mac capacity and isolation plan before increasing Agent concurrency. For temporary testing, low-risk prototypes, or short-lived experiments, shared execution may remain reasonable. For sustained Apple builds, signing, release work, or unattended tasks, an independent Mac layer is the safer operating choice.