Skip to content

Create sandboxes

In Azure Logic Apps Automation, use a sandbox as an isolated compute environment where a Managed Agent can run commands, work with files and cloned repositories, and use repository skills.

  • A Microsoft work or school account in the same Microsoft Entra tenant as the environment creator-owner.

    Your account must exist in the same tenant so the environment creator-owner can add you to the environment. You don’t need an Azure subscription to create apps and workflows in an automation environment.

  • Access to the Azure Logic Apps Automation portal.

  • Access to your automation environment.

  • To create a prebuilt sandbox configuration, the Contributor or Author role on the environment resource.

    If you don’t have environment access, contact the environment creator-owner so they can add you with the required permissions.

  • To clone a private GitHub repository by using OAuth, the Logic Apps Automation GitHub App must be installed for the GitHub account or organization that owns the repository and configured with access to that repository. Go to GitHub Apps - Logic Apps Automation, select Configure, and grant the app access to the repository. If you can’t configure the installation for an organization, ask a GitHub organization owner to grant access.

  • To use a sandbox in a workflow:

The default sandbox provides the fastest way to try Managed Agent tasks in a clean environment. You don’t create a sandbox configuration or add repositories. The platform starts the default base image on demand for each run.

  1. In the Azure Logic Apps Automation portal, open your environment, app, and workflow.

  2. On the workflow designer, select the Managed Agent action.

  3. In the action information window, select the Harness tab.

    Managed Agent Harness tab showing GitHub Copilot as the harness type and the default sandbox base image selected.

  4. Under Sandbox, for Harness Type, select GHCP (GitHub Copilot) as the harness runtime to use for agent execution.

    GHCP (GitHub Copilot) is the default harness and the only available option at this time.

  5. For Sandbox Configuration, keep (Default — base image) selected.

    To use cloned repositories or repository skills, see Create a prebuilt sandbox.

    To provide files from earlier workflow actions, see Pass input files to a Managed Agent.

  6. When you finish, close the action information window.

When the workflow runs, the Managed Agent runs in a new isolated sandbox instance based on the default image.

When a Managed Agent needs cloned repositories, repository skills, or a specific compute size, create a reusable prebuilt sandbox configuration. Creating the configuration builds an image that workflows across apps in the environment can use.

  1. In the Azure Logic Apps Automation portal, open your environment.

  2. On the environment sidebar, select Sandboxes, and then select Create.

    Screenshot that shows the automation portal with an open environment, Sandboxes menu item selected and Create button selected.

  3. In the sandbox setup window, provide the following information:

    PropertyDescription
    NameThe name for the sandbox configuration. Use only lowercase letters, numbers, and hyphens. The name default is reserved. You can’t change the name after creation.
    Resource tierThe CPU, memory, and disk budget for each sandbox instance. The default tier is M.
    RepositoriesOne or more repositories to clone into the image. At least one repository is required. For each repository, provide the URL, branch, and authentication type. Repository URLs must start with https:// or http://.

    The following resource tiers are available:

    TierCPUMemoryDisk budget
    XS0.25 core0.5 GB5 GB
    S0.5 core1 GB10 GB
    M1 core2 GB20 GB
    L2 cores4 GB40 GB

    The following table shows the authentication that sandboxes support:

    AuthenticationAzure DevOpsGitHub
    Managed identityYes, give repository read access to the environment’s managed identityNo
    Personal access token (PAT)YesYes
    OAuthYesYes
  4. If you chose OAuth, follow these steps:

    1. Enter a recognized GitHub or Azure DevOps repository URL.

    2. For a private GitHub repository, confirm that the Logic Apps Automation GitHub App has access to the repository. Go to GitHub Apps - Logic Apps Automation, select Configure, choose the account or organization that owns the repository, and then grant access to the repository.

    3. Select Connect GitHub or Connect Azure DevOps, based on the repository URL.

    4. Complete the authorization window. The repository card shows the connected service and connection when authorization succeeds.

  5. To add another repository to the sandbox, select Add repo.

  6. When you finish, select Create.

    The portal starts to build the sandbox, which shows the State property set to Building. The first build might take a few minutes to finish. Larger repositories can take longer.

    When the build completes, the State property changes from Building to Ready.

    If the state changes to Failed, select the configuration and review the error details.

  1. In your environment, open your app and your workflow.

  2. On the workflow designer, select the Managed Agent action.

  3. In the action information window, select the Agent harness tab.

  4. Under Execution environment, for Harness type, select GHCP (GitHub Copilot) as the harness runtime to use for agent execution.

    GHCP (GitHub Copilot) is the default harness and the only available option at this time.

  5. Under Sandbox configuration, select the configuration you created.

    The list normally includes only configurations in the Ready state.

  6. To optionally add repository skills, under Repository skills, select Add skill, and then provide the following information:

    PropertyDescription
    RepositoryA repository cloned by the selected sandbox configuration.
    Skills folder pathThe relative path to a folder that contains a SKILL.md file, for example, skills/code-review.

    You can add multiple skill folders. Skills require a selected prebuilt sandbox because they reference files in cloned repositories.

  7. When you finish, close the action information window.

When the workflow runs, the platform starts an isolated instance from the prebuilt image and makes the selected skills available under .github/skills.

How Azure Logic Apps Automation places skills for GitHub Copilot

Section titled “How Azure Logic Apps Automation places skills for GitHub Copilot”

Azure Logic Apps Automation follows the GitHub Copilot CLI agent skill placement. GitHub Copilot expects each project skill to have its own directory under a supported skills root, such as .github/skills, with a file named exactly SKILL.md at the root of that directory:

.github/
└── skills/
└── code-review/
├── SKILL.md
└── scripts/
└── check-changes.ps1

The SKILL.md file uses YAML frontmatter to provide the skill name and description, followed by the instructions that Copilot follows:

---
name: code-review
description: Reviews code changes for correctness and maintainability.
---
Inspect the changed files, identify high-confidence problems, and explain each finding.

Your repository doesn’t have to store the source skill under .github/skills. You can keep the skill in another folder and select that folder in Azure Logic Apps Automation. For example, suppose the cloned repository contains:

contoso-app/
└── automation-skills/
└── code-review/
├── SKILL.md
├── reference.md
└── scripts/
└── check-changes.ps1

On the Managed Agent, select the contoso-app repository and enter automation-skills/code-review for Skills folder path. Azure Logic Apps Automation performs the following setup:

  1. Confirms that the folder is inside the selected cloned repository.

  2. Confirms that SKILL.md exists at the root of the selected folder.

  3. Copies the complete skill folder, including referenced files and scripts, into the sandbox’s Copilot skills location:

    .github/skills/code-review/
  4. Starts the GitHub Copilot harness with skill discovery enabled. Copilot can then choose the skill based on the description in SKILL.md.

You can upload files from earlier workflow actions into the Managed Agent’s workspace before the agent starts.

  1. On the workflow designer, select the Managed Agent action.

  2. Select the Parameters tab.

  3. Under Input files, select Add item.

  4. For File Name, enter the name that the file should have in the sandbox workspace, for example, orders.json or report.pdf.

  5. For Content, enter an expression that gets the output from an earlier workflow action.

    For example, the following expression gets the body output from an action named Get blob:

    @{body('Get_blob')}

  6. Add more files as needed, and then close the action information window.

Input files work with the default and prebuilt sandboxes.

The Managed Agent returns files that it creates at the top level of the sandbox working directory in the fileOutputs array. Each array item contains:

PropertyDescription
pathThe file path relative to the sandbox working directory.
contentA string for text files, or a content envelope with the content type and base64-encoded data for binary files.
sizeThe file size in bytes.

Use the following expression to get the complete array in a downstream action:

@outputs('<managed-agent-name>')?['fileOutputs']

On the environment’s Sandboxes page, select a configuration to review its state, creation time, resource tier, repositories, authentication types, and any build error.

If you created the configuration, you can perform the following actions:

ActionResult
EditChange the resource tier, repository settings, branches, or authentication. Saving starts a new image build. The configuration name can’t change.
RebuildBuild a new image from the existing settings and repository connections. Use this action to pick up newer repository contents. You can’t start another rebuild while a build is already in progress.
DeletePermanently delete the sandbox configuration. This action can’t be undone.
ProblemTry
The agent action doesn’t show the agent harness tab.Make sure you selected a Managed Agent, not a different action.
Sandbox state stays In progressRefresh the sandbox list. For a long-running build, check the repository size, URL, branch, and credentials.
Sandbox state shows FailedSelect the configuration and review the error. Common causes include an invalid repository URL or branch, an expired PAT, a failed OAuth connection, or missing managed identity repository access. Correct the configuration, and then save or rebuild it.
A configuration doesn’t appear on the Managed AgentWait until its state is Ready, and then reopen or refresh the workflow.
Rebuild reports that a build is already in progressWait for the current build to reach Ready or Failed, and then rebuild again.
OAuth doesn’t show a provider-specific connect buttonMake sure the repository URL is a recognized GitHub or Azure DevOps URL.
The Managed Agent doesn’t use an input fileConfirm that the file name isn’t empty and that the content expression returns the expected value from the earlier action. Review the Managed Agent’s inputs in run history.
A generated file is missing from fileOutputsMake sure the agent copied the final file to the top level of the sandbox working directory, not a repository or skill subdirectory.
A repository skill isn’t availableConfirm that the selected sandbox is Ready, the repository belongs to that configuration, the folder path is relative to the repository, and the folder contains SKILL.md.