lgr.yaml

lgr.yaml

lgr.yaml describes an agent. The plugin and lgr import write one from what the folder already has, and lgr deploy reads it. A folder uploaded in the console uses its lgr.yaml when it has one. Paths are relative to the file.

name: support-bot
harness: codex
model:
  name: tensorblock/gpt-6.1-sol
instructions: ./AGENTS.md
skills: ./.claude/skills/        # or a list of skill folders or names
files: [scripts, data, requirements.txt]
setup: pip install --user -r requirements.txt
mcp_servers:
  - name: linear
    url: https://mcp.linear.app/mcp
    secret: LINEAR_TOKEN
  - name: crm
    command: python3
    args: [scripts/crm_mcp.py]
    env: { CRM_TOKEN: "${CRM_TOKEN}" }
secrets: [LINEAR_TOKEN, CRM_TOKEN]
egress:
  allow: [api.zendesk.com, "*.githubusercontent.com"]
limits:
  max_minutes: 30
improvement:
  mode: manual

Only name is required.

Fields

FieldMeaning
nameThe agent's name in the project. Deploying the same name again adds a version.
harnesscodex, claude-code or lagrange, or { command, args } for your own harness. Without one, the agent gets the platform's default harness and keeps it until a deploy names another.
modelname is the main model, such as tensorblock/gpt-6.1-sol. Without it, the harness's default platform model is used, or your own provider key when the project has one.
instructionsA file (./AGENTS.md, ./CLAUDE.md) or the instructions as text.
skillsA folder of skills (each a folder with a SKILL.md), or a list of skill folders or names. The harness loads them where it normally looks for skills.
filesFiles and folders copied into the run's working directory: scripts, data, dependency files, local MCP servers. Only listed files are uploaded. Never list .env or other files that hold keys.
setupA command or list of commands run in the working directory before the harness starts, such as pip install --user -r requirements.txt. A failing command fails the run with its output.
mcp_serversMCP servers the agent can use; see below.
secretsNames of project secrets passed to the run as environment variables.
egress.allowHosts the agent may reach while it works; see below.
limitsmax_minutes, max_cost_usd and max_turns per run.
improvement.modeoff stops LagrangeCloud from proposing improvements on its own.

MCP servers

A server either runs somewhere else and is reached by URL, or runs inside the sandbox as a command.

mcp_servers:
  # Hosted: the secret is sent as a bearer token.
  - name: linear
    url: https://mcp.linear.app/mcp
    secret: LINEAR_TOKEN
  # In the sandbox: ${NAME} in env is filled from project secrets.
  - name: github
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env: { GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}" }

The sandbox is Linux with Node.js 22 and Python 3. npx -y packages work as they are; install Python servers under setup with pip install --user. A server whose command is a path on your machine has to be listed under files and referenced by its path in the folder.

Servers that run on localhost, or that you signed in to through a browser, can't be reached from the cloud. Add a hosted URL with a token, or a command the sandbox runs, on the agent's page under Setup → MCP servers and secrets. Each change there saves a new version.

Secrets

Secrets are stored per project, write-only: nothing shows their values after they are set. Set them under Settings → Secrets, or:

lgr secrets set LINEAR_TOKEN CRM_TOKEN --from-env   # from the environment, .env or your Codex config
echo -n "$VALUE" | lgr secrets set STRIPE_KEY       # from stdin

A deploy warns about secrets the agent lists that the project hasn't set.

Egress

Without egress, the agent can reach any public host. With egress.allow, it can reach only the hosts listed: example.com matches that host, *.example.com its subdomains. The model API and the agent's hosted MCP servers are always allowed, and setup commands may reach any public host. Blocked connections show up as egress blocked lines in the run's log. Private and loopback addresses are never reachable.

What a run does

Each run on a fresh sandbox:

  1. SkillsUnpacked where the harness loads them
  2. FilesCopied into the working directory
  3. SetupYour setup commands run there
  4. RunMCP servers and the harness start with the message
  5. ResultThe reply, files and trace come back

Instances prepare once per version and keep what they were set up with.