Skip to main content
MDM rollout is available on Enterprise plans only.
If your enterprise uses an MDM (Mobile Device Management) tool, you can provision Corridor across all employees automatically. With MDM, developers don’t need to separately install the Corridor extension or sign up—everything is handled for them.

Supported platforms

Supported IDEs/coding agents

  • VS Code
  • Devin Desktop
  • Cursor
  • Claude Code (via Corridor CLI)
  • Codex (via Corridor CLI)
  • Factory Droid (via Corridor CLI)

Prerequisites

Verifying a domain

In order to use the MDM scripts, you must verify an email domain for your team. Corridor will only provision users with the email domain you have verified.
1

Navigate to Teams

2

Enter your domain

Go to the Domain Verification section and enter your organization’s domain name (e.g., acme.com).
3

Add DNS record

Copy the DNS TXT record provided and add it to your DNS provider.

Creating a universal team token

In order to use the MDM scripts, you must create a universal team token to identify your team and verify your team admin access.
1

Navigate to Teams

2

Generate a token

Under Universal Team Tokens, click Generate New Tokens. Add a token name and select an expiration date.
3

Copy the token

Copy the universal team token—you’ll use it in the MDM scripts below.

Managing PATH yourself

By default the installer adds ~/.corridor/bin to PATH by appending a small block to one of the user’s shell profiles (~/.zshenv for zsh, the existing bash login profile on macOS, ~/.bashrc on Linux). The entry is always appended, never prepended, so system binaries keep priority, and it is guarded so nested shells don’t accumulate duplicate PATH entries. If you provision PATH through a managed profile instead, tell the installer to leave shell profiles alone:
  • macOScurl -fsSL https://app.corridor.dev/cli/install.sh | bash -s -- --no-path-modify
  • Windows, or anywhere you prefer an environment variable — set CORRIDOR_NO_PATH_MODIFY=1
The binary still installs to ~/.corridor/bin/corridor (%USERPROFILE%\.corridor\bin\corridor.exe on Windows), so make sure your managed profile puts that directory on PATH—or invoke the absolute path in scripts and hooks.

fish users

fish reads none of the POSIX profiles above. For a fish login shell the installer instead writes its PATH block to config.fish, in native fish syntax, under $XDG_CONFIG_HOME/fish/ when that variable is set (and absolute) or ~/.config/fish/ otherwise. Two consequences for managed installs:
  • Run the installer with the target user’s environment. fish reads config.fish from the user’s XDG_CONFIG_HOME at login. If you run the installer with a different (or unset) XDG_CONFIG_HOME than the user’s fish session sees, the block lands where that session never reads it. Run the install step as the target user, or export their absolute XDG_CONFIG_HOME for the install. A relative XDG_CONFIG_HOME is rejected (the installer cannot predict the directory fish will resolve it against).
  • Mixed-shell machines. config.fish is authoritative for fish. A corrected PATH block a previous install wrote to a POSIX profile is left in place, so a user who also runs sh/bash keeps corridor resolving there; only an old Corridor-managed ~/.local/bin prepend is stripped.
Opting out also leaves any ~/.local/bin PATH prepend an older installer wrote in place. That directory takes priority over system binaries, so if your fleet installed Corridor before this change, strip the # Added by Corridor CLI installer block from the shell profile as part of your rollout (the CLI also corrects it on its next run).

JAMF (macOS only)

For JAMF, you must create a configuration profile to push the User email and Device serial fields to each managed computer.

Creating a configuration profile

Prerequisites

To set up a JAMF configuration profile, you must have:
  • A push certificate in JAMF Pro. See instructions here.
  • The Enable certificate-based authentication and Enable push notifications settings configured in Jamf Pro. For more information, see Security Settings.
To create the configuration profile:
1

Add configuration profile

In JAMF, go to Computers -> Configuration Profiles. Click New.
2

Setup configuration profile

Set a name like ‘Push plist for Corridor’ with level ‘Computer Level’ and Distribution Method ‘Install automatically’. Set ‘Scope’ to ‘All computers’, or just all the computers you want to have access to Corridor.
3

Upload plist

Go back to ‘Options’, and search for ‘Application & Custom Settings’. Click the arrow underneath, and click ‘Upload’. Click ‘Add’. Set the preference domain to dev.corridor.mdm and set the file contents to
Or download dev.corridor.mdm.plist and upload those contents.
4

Save configuration

Save your configuration and check that it was pushed to your devices.

Add the Corridor script

1

Create a script

In JAMF, go to Settings and search for Scripts. It should be under Computer management.
2

Download the script

Download the Corridor JAMF script:
3

Add your token

Replace the CORRIDOR_TEAM_TOKEN value at the top of the file with the universal team token you generated.
4

Upload and save

Name the script something along the lines of Corridor Installation Script, and upload the script with the shell/bash language option. Save the script.

Create a policy

1

Create a policy

In JAMF, go to Computers and then Policies. It should be under Content management. Click ‘New’.
2

Set the policy

Set the policy name to be ‘Corridor Installation Policy’. Select ‘Recurring Check-in’ as the trigger (unless otherwise desired), with the execution frequency as ‘Once per computer’. Click ‘Automatically re-run policy on failure’. Set the scope as desired (All computers or specific computers).
3

Add the script to the policy

In options, click Scripts and choose ‘Configure Scripts’. Add the Corridor Installation Script you created in the previous step, and save the policy.
Now, just wait for the scripts to run on the computers the policy is pushed out to. Once users restart their IDEs, they should be automatically signed in to Corridor and the extension installed.

Fleet (macOS only)

For Fleet, you must deploy a configuration profile that pushes the User email and Device serial fields to each managed Mac, then run the Corridor script. Fleet can only substitute its per-host variables into configuration profiles, not into scripts, so both are required.

Prerequisites

  • Fleet Premium with MDM enabled on your macOS hosts (the configuration profile requires MDM). Script execution is on by default for MDM-enrolled hosts; otherwise deploy fleetd with --enable-scripts.
  • Each host must have an end user in Fleet, through your IdP integration or a human-to-host mapping. Without one, Fleet cannot resolve the profile’s variables and the profile will not deliver.
  • A user must be logged in on the Mac when the script runs (a locked screen is fine). At the login window the script skips and retries later, so credentials are not written to the wrong home directory.

Store your team token as a Fleet custom variable

1

Add the custom variable

In Fleet, go to Controls → Variables and add a custom variable named CORRIDOR_TEAM_TOKEN with your universal team token. Do not paste the token into the script. Reference it as $FLEET_SECRET_CORRIDOR_TEAM_TOKEN (Fleet adds the FLEET_SECRET_ prefix and masks the value).

Creating a configuration profile

1

Download the profile

Download the Corridor Fleet configuration profile:
2

Upload and scope

In Fleet, go to Controls → OS settings → Configuration profiles and upload the profile, scoped to the fleet that contains your target hosts. It writes $FLEET_VAR_HOST_END_USER_IDP_USERNAME and $FLEET_VAR_HOST_HARDWARE_SERIAL to /Library/Managed Preferences/dev.corridor.mdm.plist.
3

Confirm delivery

On a test Mac:
You should see UserEmail and SerialNumber. If the profile fails with a missing IdP username error, set the host’s IdP username (email) on the host details page. Fleet resends once it resolves.

Add the Corridor script

1

Download the script

Download the Corridor Fleet script:
2

Upload and save

In Fleet, go to Controls → Scripts and upload the file. Leave the $FLEET_SECRET_CORRIDOR_TEAM_TOKEN reference as-is.

Run the script

1

On demand

Go to Hosts, select a host, then Actions → Run script. From the CLI:
2

Automatically

Attach the script to a policy automation so it runs as hosts come into scope.
Once users restart their IDEs, they are automatically signed in to Corridor and the extension is installed.

Kandji / Iru (macOS only)

For Kandji (including Iru, Kandji’s new UI), you must deploy a custom profile that writes Kandji’s global variables to each device before running the Corridor script.
Iru does not include classic Kandji’s Global Variables feature, so global variables are never written to devices unless you deploy them with a Custom Profile. The steps below use Kandji’s official Global Variables profile and work in both classic Kandji and Iru.

Create a custom profile

1

Download the official Global Variables profile

Download the official Global Variables.mobileconfig provided by Kandji. When the profile is pushed to a device, Kandji substitutes its built-in global variables (including $EMAIL and $SERIAL_NUMBER) and writes them to /Library/Managed Preferences/io.kandji.globalvariables.plist — the file the Corridor Kandji script reads at runtime.
2

Add custom profile

In Kandji or Iru, go to Library and add a Custom Profile.
3

Upload the profile

Upload the Global Variables.mobileconfig file to the Custom Profile and save it.
4

Attach to your Blueprint

Assign the Custom Profile to the Blueprint(s) where you want to deploy Corridor — the same Blueprint(s) you assign the Corridor script to in the next section.
If you author your own profile instead of using Kandji’s, the keys must be named exactly EMAIL and SERIAL_NUMBER — these are the names the Corridor Kandji script reads at runtime. If your variables use different keys, you will have to change the DEVICE_SERIAL and USER_EMAIL variables in the script (the PlistBuddy print statements) to match.

Add the Corridor script

1

Create a custom script

In Kandji or Iru, go to Library and add a Custom Script. Assign it to the same Blueprint(s) as the Custom Profile above. Select Execution Frequency: Run once per device.
2

Download the script

Download the Corridor Kandji script:
3

Add your token

Replace the CORRIDOR_TEAM_TOKEN value at the top of the file with the universal team token you generated.
4

Upload and save

Upload the file with the correct CORRIDOR_TEAM_TOKEN to Kandji and click Save.

Intune

Intune scripts support both macOS and Windows. You must first generate a Microsoft Graph token with the right permissions—this token is used to retrieve the device email.

Generate a Microsoft Graph token

1

Open Graph Explorer

Go to Microsoft Graph Explorer and sign in.
2

Set permissions

Click Modify Permissions and consent to User.Read permissions. This requires Admin consent.
3

Copy the token

Refresh the page, then click Access token and copy the Microsoft Graph API access token.

Windows

1

Navigate to scripts

On intune.microsoft.com, go to Devices → Scripts and remediations under Manage Devices.
2

Add a script

Click Platform scripts → Add → Windows 10 and Later. Set a name and description.
3

Download the script

Download the Corridor Intune Windows script:
4

Add your tokens

In the script, replace the CORRIDOR_TEAM_TOKEN value with your universal token, and replace the GRAPH_API_TOKEN value with the Microsoft Graph API access token.
5

Configure script settings

Select Yes for “Run this script using the logged on credentials”, No for “Enforce script signature check”, and No for “Run script in 64 bit Powershell Host”.
6

Assign and save

Assign the script to the selected group of devices and click Save. Sync all devices with bulk device actions to force the script to run.

macOS

1

Navigate to scripts

On intune.microsoft.com, go to Devices → Scripts and remediations under Manage Devices.
2

Add a script

Click Platform scripts → Add → macOS. Add a name and description.
3

Download the script

Download the Corridor Intune macOS script:
4

Add your tokens

In the script, replace the CORRIDOR_TEAM_TOKEN value with your universal token, and replace the GRAPH_API_TOKEN value with the Microsoft Graph API access token.
5

Configure script settings

Select Yes for “Run script as signed-in user” and 1 time for “Max number of times to retry if script fails”.
6

Assign and save

Assign the correct groups to the script and click Save. Sync all devices with bulk device actions to force the script to run.

Rolling back a deployment

You don’t need a custom teardown script — the Corridor CLI ships an uninstaller that reverses everything the rollout does. Rolling back has two independent halves, and you’ll usually want both:
  1. Stop provisioning so no device gets (re)installed.
  2. Remove Corridor from devices that were already provisioned.

1. Stop provisioning

  • Unscope or delete the Corridor install policy (and, for JAMF, the dev.corridor.mdm configuration profile) in your MDM, so devices stop receiving the install.
  • (Optional, org-wide kill switch) Revoke the Universal Team Token. Go to app.corridor.dev/teamsUniversal Team Tokens and revoke the token used in your MDM scripts. Once revoked, any /mdm-sync-device call fails, so no new users or device tokens are created. Devices already provisioned keep their per-user token until you run the uninstall below.

2. Remove Corridor from a device

Run the uninstaller as the logged-in user. It revokes that device’s Corridor API token on the server and removes the CLI, agent hooks, MCP config, agent rules, and the ~/.corridor/ directory:
Or, if the CLI binary is still present, call it directly:
The uninstaller removes Corridor’s hooks, MCP config, agent rules, and credentials, but leaves the Corridor IDE extension itself installed (it’s inert once the token is revoked). To also remove the extension binary, uninstall it per IDE — e.g. code --uninstall-extension corridor.Corridor and cursor --uninstall-extension corridor.Corridor. The JAMF script below does this for you.
Push the uninstall through your MDM the same way you pushed the install.
Prefer running the uninstaller as the logged-in user. Some MDMs (such as Kandji) run custom scripts as root. When uninstall.sh runs as root, it resolves the logged-in console user and removes that user’s install. Set CORRIDOR_UNINSTALL_USER=<username> to name the target user when detection is unavailable. When no user is logged in, it acts on root’s own home, so a root-owned install (for example in a container or CI image) is still removed. On macOS, if no console user resolves and root’s home holds no install either, it exits non-zero so the MDM retries at the next check-in instead of reporting a false success.The JAMF script below resolves the console user itself and runs the uninstaller as that user. It exits 0 when no one is logged in, so the policy retries at the next check-in.

JAMF (macOS only)

1

Add an uninstall script

In JAMF, go to Settings → Scripts and create a new script (shell/bash) named something like Corridor Uninstall Script, with these contents:
2

Create an uninstall policy

Go to Computers → Policies → New. Name it Corridor Uninstall Policy, add the Corridor Uninstall Script under Scripts, set the trigger to Recurring Check-in with execution frequency Once per computer, and scope it to the devices you’re rolling back.
3

Remove the install policy and profile

After the uninstall has run, unscope or delete the Corridor Installation Policy and the dev.corridor.mdm configuration profile so devices are not re-provisioned on their next check-in.

Fleet (macOS only)

1

Upload a rollback script

In Fleet, go to Controls → Scripts and upload a rollback script whose contents are:
2

Run and clean up

Run it via Actions → Run script or fleetctl run-script. Then remove the Corridor script from any policy automation and delete the dev.corridor.mdm configuration profile so hosts are not re-provisioned.

Kandji / Iru (macOS only)

Add a Custom Script (Execution Frequency: Run once per device) whose contents are curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash, assign it to the Blueprint you’re rolling back, then remove the Corridor Custom Script and the Global Variables profile from that Blueprint.

Intune

Add a platform script that runs the uninstaller, then unassign the install script:
  • macOS — set Run script as signed-in user: Yes and use curl -fsSL https://app.corridor.dev/cli/uninstall.sh | bash.
  • Windows — set Run this script using the logged on credentials: Yes and run the CLI directly: & "$env:USERPROFILE\.corridor\bin\corridor.exe" uninstall --non-interactive.