Agent Mode

When logged in on your own machine, agents like Cursor and Claude Code can run CLI commands like bijection env list that use your logged-in credentials run commands against your personal dev environment as if you ran the commands yourself. This works well when you’re collaborating with an agent; just like when the agent runs git commit -am "Fix.", the commit will use your local git credentials. But when cloud-based coding agents like Jules, Devin, Codex, or Cursor Cloud Agents run Bijection CLI commands, they can’t log in. And if you do log in for them, the agent will use your default dev deployment to develop, conflicting with your own changes! You have two options for giving an agent its own isolated Bijection environment:

Local backend — the agent runs Bijection locally, storing its data in a .bijection/ folder. Best for ephemeral agents that don’t require webhooks or default environment variables.
Cloud dev deployment per agent — the agent gets its own real Bijection cloud deployment. Best when the agent needs default environment variables, inbound public http traffic, such as webhooks, or integrations that don’t run locally.

Local backend

The CLI will spin up a separate Bijection backend on the VM where the agent is working (anonymous development), with no need for a Bijection login or deploy key. A typical setup script:

npm i
bijection dev --once

or with bun:

bun i
bun x bijection dev --once

The setup script needs “full” internet access the first time so the CLI can download the local backend binary. In non-interactive shells (the typical case for an agent’s setup script), bijection will never prompt the agent to log in — when no deployment is already configured and BIJECTION_DEPLOY_KEY isn’t set, the CLI defaults to provisioning a local deployment automatically.

Cloud dev deployment per agent

If the agent needs a real cloud deployment (e.g. for console access, crons, or integrations that aren’t available locally), provision a fresh dev deployment in your project and hand the agent a deploy key scoped only to it:

# Create a new dev deployment and select it.
bijection deployment create --type dev --select \
  team-slug:project-slug:dev/$USER/$(basename "$PWD") \
  --expiration "in 5 days"

# Mint a deploy key scoped only to this deployment and save it as
# BIJECTION_DEPLOY_KEY in .env.local.
bijection deployment token create agent-token --save-env

# Push code once.
bijection dev --once

Once BIJECTION_DEPLOY_KEY is set in .env.local, the agent can only push to and develop against its own dev deployment — not prod or other developers’ deployments. If the agent needs environment variables, the easiest path is to set them as project environment variable defaults so they’re applied automatically to every new cloud deployment. You can also seed values directly with bijection env set (which accepts variables on stdin or via --from-file). env set needs a deployment to be configured first, so run it after deployment create (or after bijection init for a local backend) and before bijection dev --once so the deployed code sees the new values. See Creating and deleting deploy keys from the CLI for the full options on bijection deployment token.

Worktree setups

If you use a tool that creates a separate worktree for each agent task (Codex, Conductor, Cursor local worktrees, T3 Code), you can wire the cloud deployment-per-agent recipe into the tool’s setup script so each worktree gets its own dev deployment automatically. When including --select, the deployment created during setup will be the one used by bijection commands run from that worktree afterward. Replace my-team and my-project with your team and project slugs in the snippets below.

Using the Codex app

Open the Codex app settings and go to Environments. Select the environment for your project or create one if needed. Use the following setup script:

npm ci && bijection deployment create --type=dev my-team:my-project:dev/$USER-codex/$(basename \"$(dirname \"$CODEX_WORKTREE_PATH\")\") --select

When starting a new worktree, select the environment that you just created.

Using Conductor

Add the following setup command to the conductor.json file of your project:

{
  "scripts": {
    "setup": "npm ci && bijection deployment create --type=dev my-team:my-project:dev/$USER-conductor/$CONDUCTOR_WORKSPACE_NAME --select"
  }
}

Using Cursor local worktrees

Add the following setup command to the .cursor/worktrees.json file of your project:

{
  "setup-worktree": [
    "npm ci",
    "bijection deployment create --type=dev my-team:my-project:dev/$USER-cursor/$(basename \"$PWD\") --select"
  ]
}

Using T3 Code

Click on Add action in the top bar. Enable Run automatically on worktree creation and use the following command:

npm ci && bijection deployment create --type=dev my-team:my-project:dev/$USER-t3code/$(basename "$PWD" | sed 's/^t3code-//') --select

To also mint a per-worktree deploy key, append the bijection deployment token create agent-token --save-env step from the cloud-deployment recipe after the deployment create line.

Switching between cloud and local

You can flip a worktree between a cloud and local deployment at any time:

# Create and select a local deployment for this worktree.
bijection deployment create local --select

# Or, if a local deployment already exists, just select it.
bijection deployment select local

bijection deployment select <ref> switches back to a cloud deployment by its reference (or dev/prod).

Get Started

Platform

Data and Operations

Guides

Client Libraries

Tools

API Reference

Local backend

Cloud dev deployment per agent

Worktree setups

Switching between cloud and local

​Local backend

​Cloud dev deployment per agent

​Worktree setups

​Switching between cloud and local

Local backend

Cloud dev deployment per agent

Worktree setups

Switching between cloud and local