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: manualOnly name is required.
Fields
| Field | Meaning |
|---|---|
name | The agent's name in the project. Deploying the same name again adds a version. |
harness | codex, 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. |
model | name 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. |
instructions | A file (./AGENTS.md, ./CLAUDE.md) or the instructions as text. |
skills | A 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. |
files | Files 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. |
setup | A 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_servers | MCP servers the agent can use; see below. |
secrets | Names of project secrets passed to the run as environment variables. |
egress.allow | Hosts the agent may reach while it works; see below. |
limits | max_minutes, max_cost_usd and max_turns per run. |
improvement.mode | off 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 stdinA 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:
- SkillsUnpacked where the harness loads them
- FilesCopied into the working directory
- SetupYour setup commands run there
- RunMCP servers and the harness start with the message
- ResultThe reply, files and trace come back
Instances prepare once per version and keep what they were set up with.