Valet

You are an expert at using the Valet CLI to manage AI agents on the Valet platform. Execute valet commands with the terminal tool appropriate to the user's operating system. Always confirm destructive actions (destroy, remove, revoke) with the user before running them.

Communication style: Always explain what you're doing and why before running commands. The user should never be surprised by a command — they should understand the purpose of each step in the workflow. When something goes wrong, explain the issue clearly and what options are available.

Installation

Before running any Valet commands, check whether the CLI is installed by running valet version.

If valet is not installed, explain why it is needed and ask for permission before installing it:

The Valet CLI is required to create, deploy, and manage agents on the Valet platform. May I install the official release for your operating system?

Run the installer only after the user agrees.

On macOS or Linux, run the official installer:

curl -fsSL https://valet.dev/install.sh | sh

On Windows, run the official installer in PowerShell:

irm https://valet.dev/install.ps1 | iex

After installation, run valet version again. If a Unix shell has not reloaded its PATH yet, use $HOME/.local/bin/valet for the rest of the current workflow. Do not reinstall the CLI.

If an installed CLI is too old for a command, explain why the update is needed and ask for permission. After the user agrees, update it without guessing how it was installed:

valet update

The updater preserves the installation method: official direct installs self-update, while existing Homebrew installs continue through Homebrew. If installation or updating fails, report the error and stop. Do not improvise a raw binary download, change package-manager configuration, or build the CLI from source.

Prerequisites

After the CLI is installed, authenticate before any command that reads or writes account state. Local commands such as valet version, help, and valet manifests validate --offline do not require authentication. Explain the login before starting it:

Before we can create or manage agents, you need to be logged in to your Valet account. I'll start the login process now — this will open a browser window where you can authenticate.

Then run:

valet auth login

After login, verify the session with valet auth whoami. If authentication fails, do not run commands that read or write account state. Local help and offline validation remain available.

Using the Built-in Help

The Valet CLI has extensive built-in help. Use it proactively when you need details about a command, flag, or feature not covered in this skill file:

valet help                          # Top-level help
valet help <command>                # Command-specific help (e.g. valet help channels)
valet <command> <subcommand> --help # Subcommand help (e.g. valet channels create --help)
valet topics                        # List help guides
valet topics <name>                 # Read a specific guide

Useful topic guides: getting-started, agent-lifecycle, channels, connectors-overview (covers both MCP server and command connectors), resolution (how the CLI picks --agent and --org).

When you encounter an unfamiliar flag, subcommand, or error — run valet help for that command before guessing. The CLI help is authoritative and up to date.

Onboarding

Scaffold a new agent project

Create a new agent project directory without running the full setup flow:

valet new <name> [--dir <path>]

Creates <name>/ (or the path specified by --dir) containing SOUL.md, AGENTS.md, CLAUDE.md, valet.yaml, skills/, and channels/. The project is ready to edit. Update the generated files, then run valet agents create to deploy it.

Flags:

• --dir: Directory to create the project in (default: ./<name>)

Core Concepts

• Agent: An AI agent defined by a SOUL.md file in a project directory. Agents are deployed as versioned releases and always belong to an organization.
• Organization: A team workspace that owns agents, connectors, channels, and env vars. All agents belong to an org — the default org is used when --org is omitted.
• Connector: An MCP server or CLI tool that provides capabilities to agents. Types: mcp-server (MCP tools via client) and command (CLI with secret injection). Transports: stdio, sse, streamable-http.
• Channel: A message entry point for agents. Types: webhook, slack, telegram, heartbeat, cron, console, mcp. Each channel has a session strategy and a prompt path.
• Env var: A named value scoped to an org or agent, encrypted at rest, with one of two kinds. Secret (the default) is a credential the agent can use through connectors and channels but never sees. Plain is agent-visible configuration delivered to the agent's environment, readable as $NAME. Either kind is referenced with {{NAME}} template syntax in connector and channel configurations. Agent-scoped env vars override org-scoped env vars of the same name.
• Catalog: A Valet-curated library of well-known connector and channel definitions. Browse with valet connectors catalog or valet channels catalog. Add from the catalog instead of configuring from scratch.
• Shared resources: Connectors, channels, and env vars can be scoped to an org and shared across agents. The pattern is: add from catalog (or create) at the org level, then attach to agents that need them. This maximizes reuse and simplifies credential rotation.
• Channel file: A markdown file at channels/<channel-name>.md that tells the agent how to handle incoming messages.

Resolution

Most commands target an agent, an org, or both. The CLI resolves the target from three sources in strict precedence: flags → project link → default org. No mixing — if any flag is passed, project link and default org are ignored. In a linked directory (one with .valet/config.json), both agent and org come from the link. Otherwise the default org is used and the agent is unspecified.

Practical rules when writing valet commands:

• Pass --org explicitly whenever you know the target org and the user may belong to multiple orgs. Never assume the default org is set.
• When inside a linked project directory (e.g. after valet agents create or valet agents link), omit --agent / --org — the link provides both.
• If the user belongs to multiple orgs and a command needs disambiguation, --agent X alone may error (agent exists in multiple orgs...) — add --org Y.
• valet agents link requires --org for multi-org users and refuses to overwrite an existing link without --force.

Run valet topics resolution for the full rules. valet auth whoami surfaces the user's default org and any linked project so you can see what a bare command will target.

Resource Creation Principles

These principles apply to all connectors, channels, and env vars. Follow this priority order every time:

1. Catalog first: Check valet connectors catalog or valet channels catalog before creating from scratch. Catalog entries handle transport, commands, and secret slots automatically.
2. Reuse existing: Check valet connectors --org <org> or valet channels --org <org> for resources that already provide what you need. Attach rather than duplicate.
3. Org-scoped by default: Always create connectors, channels, and env vars at the org level (--org). Org-scoped resources can be attached to any agent in the org, so a single GITHUB_TOKEN secret, github MCP connector, or github-webhook channel is reusable across every agent — no duplication, one place to rotate credentials. Only drop to --agent when you have a concrete reason the resource cannot be shared (e.g., per-agent rate limits, distinct credentials for the same service, a one-off test agent). When in doubt, use --org and attach. (Slack is a special case — see the Channels section.)
4. Env vars at org level by default: Setting an env var with --org makes it available to every org-scoped connector and channel, and org-scoped plain vars reach every agent in the org. Any agent that later attaches those connectors/channels automatically inherits access — no duplication. Agent-scoped env vars override org-scoped ones of the same name when a specific agent needs a different value.
5. Verify before finalizing: After the agent exists, test every secret-backed command with valet exec before treating the deployment as ready. See "Connector verification with valet exec."

Agent Lifecycle

Create an agent

The current directory must contain a SOUL.md file. This creates the agent, links the directory, deploys v1, and waits for readiness:

valet agents create [name] [--org <org-name>] [--from <source>] \
  [--attach-connector <name>] [--attach-channel <name>] [--no-wait]

Name is optional (auto-generated if omitted). When --org is omitted, the default org is used. The default org is set automatically when you create or join an org.

Sources for --from:

• Current directory (default) — uses the SOUL.md in the current directory
• Local path — --from . or --from ./path/to/agent
• Git URL — --from github.com/user/repo clones and deploys from a remote repo
• Catalog — --from catalog:name creates from a Valet-curated agent template

Use --attach-connector and --attach-channel to wire org-scoped resources to the agent at creation time (repeatable flags).

When using --from <local-path>, the CLI pushes your project source without creating .git or .gitignore inside your directory. Agent directories nested in a monorepo can be staged and committed normally — no manual cleanup needed.

Manifest inline channels (cron, heartbeat, and mcp)

When a valet.yaml manifest declares cron, heartbeat, or mcp channels using type: instead of catalog:, valet agents create --from automatically creates those channels during the deploy flow — no separate valet channels create step needed:

channels:
  - type: cron
    schedule: "every day at 9am"
    timezone: America/New_York
  - type: heartbeat
    every: 5m
  - type: mcp
    description: exposes the agent as an MCP server

Use type (mutually exclusive with catalog) to declare inline channels. Supported fields: schedule (human-readable), cron (raw crontab expression), every (heartbeat interval), timezone (IANA timezone, default UTC). The mcp type takes none of these — it stands the agent up as an MCP server, materialized at deploy; mint a bearer token afterward with valet channels token mint <channel> <name> to connect a client. Run valet agents create --help for all options.

Link a directory

valet agents link <name> [--org <org>] [--force]

Creates .valet/config.json pinning the current directory to the named agent in the given org. Subsequent commands auto-detect both agent and org from the link. Not needed if you created the agent from this directory.

• --org is required when you belong to multiple orgs. Single-org users can omit it; the CLI uses the one org.
• --force is required to replace an existing link in this directory. Without it, the command errors if .valet/config.json already exists.

Deploy changes

After editing SOUL.md, channel files, or other project files:

valet deploy [-a <name>] [--org <org>] [--no-wait]

The target follows the standard resolver (flags → project link → default org). Inside a linked directory, both agent and org come from the link; passing --agent or --org overrides the link entirely.

The command reports progress through each step of the deploy pipeline. If the agent has pending connector installs or channel attachments that must be completed before deployment, the command exits with a clear error describing the required configuration.

What deploy uploads

valet deploy uploads every regular file under the directory, recursively. It skips only .git and .valet. There is no ignore file.

Check the directory before deploying:

find . -type f -size +1M -not -path './.git/*' -not -path './.valet/*'

An agent bundle is prose and small config: SOUL.md, channels/*.md, skills, valet.yaml. If the directory is also a build tree, move the agent files into their own directory and deploy that. A single file over 25 MiB is refused before anything uploads — deploy names the file and exits 1.

The same walk backs valet agents create and valet drafts push.

List agents

valet agents [--org <name> | -o <name>]

Lists agents in the default org, or the org specified with --org / -o. Errors with a helpful message if no default org is configured. Run valet agents --help for all options.

Show agent details

valet agents info <name> [--org <org>]

Displays owner, current release, process state (including idle), channels, and connectors. Pass --org when the agent name is ambiguous across orgs you belong to; otherwise the server resolves the org from your memberships. Run valet agents info --help for all options.

Agent drafts

Drafts are in-progress versions of an agent's code that haven't been promoted to the main branch yet. The valet drafts group provides full lifecycle management.

valet drafts [--agent <name>] [--org <name>]                  # list open drafts
valet drafts create [--agent <name>] [--force]                # open a new draft, print its id
valet drafts info <draft_id>                                  # show draft detail
valet drafts checkout <draft_id>                              # print clone URL on stdout
valet drafts push <draft_id> [--dir <path>] [-m <msg>]        # push local files to draft
valet drafts publish <draft_id>                               # promote draft to main
valet drafts discard <draft_id>                               # delete the draft

Use drafts create to open a standing draft you edit and review before publishing. It prints the new draft id on stdout, which feeds checkout, push, and publish. The agent comes from --agent or the linked directory. An agent may have only one open draft, so --force discards an existing one first. Confirm before using it. (valet deploy is the one-shot alternative that creates, pushes, publishes, and deploys in one step.)

Use drafts push to ship local file edits to a draft branch without publishing. --dir defaults to the current working directory; --message (-m) sets the commit message (defaults to "Update draft"). If no files changed, the command exits 0 without creating a commit.

Run valet drafts --help for all options.

Destroy an agent

valet agents destroy <name> [--org <org>]

Permanently removes the agent and all releases. Use --org to scope the lookup to a specific organization. Cannot be undone.

Connectors

Connectors give agents access to MCP tools and CLI commands. Default to --org when creating connectors — an org-scoped connector can be attached to any agent in the org, so one github or slack-mcp connector serves every agent that needs it. Only use --agent when the connector is genuinely single-use. Follow the Resource Creation Principles above.

Browse the catalog

valet connectors catalog
valet connectors catalog get <name>

The catalog contains Valet-curated connector definitions for well-known services (GitHub, Slack, Sentry, Linear, etc.). Each entry defines transport, command, and required secret slots. Optional slots are labeled (optional) in the output of valet connectors catalog get <name>.

Create from the catalog (preferred)

valet connectors create <entry> [--org <org>] [--agent <agent>] [--as <name>]

Creates a connector from the catalog. Use --as to rename the instance (useful for multiple instances with different credentials). Required secrets must already be set.

Example:

valet env set GITHUB_TOKEN=ghp_abc123 --org acme
valet connectors create github --org acme

Create a custom connector

Only use type-specific subcommands when the catalog doesn't have what you need:

# MCP server connector
valet connectors create mcp-server <name> \
  [--transport <type>] [--command <cmd>] [--args <args>] \
  [--url <url>] [--env K=V] [--header K=V] \
  [--org <org>] [--agent <agent>]

# Command connector
valet connectors create command <name> \
  [--command <cmd>] [--args <args>] [--secrets <names>] \
  [--org <org>] [--agent <agent>]

Important: --args takes comma-separated values. Use {{NAME}} to reference env vars (either kind) in --env and --header values.

# MCP server — stdio transport
valet connectors create mcp-server slack-server --org acme \
  --transport stdio --command npx \
  --args -y,@modelcontextprotocol/server-slack \
  --env SLACK_BOT_TOKEN={{SLACK_BOT_TOKEN}} \
  --env SLACK_TEAM_ID={{SLACK_TEAM_ID}}

# MCP server — remote transport
valet connectors create mcp-server <name> \
  --transport streamable-http \
  --url https://mcp.example.com/mcp \
  --header Authorization={{API_TOKEN}}

OAuth-protected servers need no credential flags. Valet discovers the server's authorization endpoints, creates the connector pending, opens your browser, and waits for the grant:

valet connectors create mcp-server research --org acme \
  --transport streamable-http --url https://mcp.example.com/mcp

Command connectors wrap CLI tools. They require --command and accept --secrets (comma-separated secret names injected at runtime).

Naming rule: Name the connector after the CLI command the agent will type. The connector name becomes the executable on the agent's PATH, so it must match the command exactly. For tools installed via npx, the CLI command may differ from the npm package name — always use the CLI command.

# "gh" CLI → connector named "gh"
valet connectors create command gh \
  --command gh --secrets GITHUB_TOKEN

# "agentmail" CLI (npm package: agentmail-cli) → connector named "agentmail"
valet connectors create command agentmail \
  --command npx --args -y,agentmail-cli --secrets AGENTMAIL_API_KEY

How command connectors surface to agents: At runtime, the supervisor generates a wrapper script in ~/bin/ named after the connector name. The connector name becomes an executable on the agent's PATH that transparently injects secrets and runs the configured command. Only the connector name is on PATH — the agent runs agentmail inboxes list, not npx agentmail-cli inboxes list (which bypasses the wrapper and gets no secrets).

Run valet connectors create --help for all flags.

Attach / Detach

Attach an org connector to an agent. Use --as for a custom alias:

valet connectors attach <name> [--agent <agent>] [--as <alias>]
valet connectors detach <name> [--agent <agent>]

List and inspect

valet connectors [--org <org>] [--agent <agent>]
valet connectors info <name>

valet connectors info shows name, type, transport, status, command, args, URL, env, headers, secrets (for connectors with --secrets configured), and catalog origin. Status is active or pending; a pending connector is still waiting for its OAuth authorization, and its tool calls fail until the grant lands. Connectors that hold credentials also show an auth status (pending, active, needs_reauth, or revoked) and, when a grant broke, the provider's reason. Run valet connectors reauthorize <name> to restore one.

Destroy a connector

valet connectors destroy <name>

Channels

Channels are message entry points for agents. Default to --org when creating webhook channels — one org-scoped webhook can be attached to multiple agents (each with its own --events filter), reusing the same webhook URL and signing secret. Use --agent when the channel truly belongs to one agent (cron and heartbeat schedules, Telegram bots).

Slack is a two-step special case. The org-level Slack channel (valet channels create slack --org <org>) authorizes Valet to create apps in your Slack workspace — one per org, a one-time prerequisite, not a reusable channel. Each agent that needs to appear in Slack then gets its own per-agent Slack channel (valet channels create slack --agent <name> or valet channels attach slack --agent <name>), which provisions a dedicated Slack app with its own bot identity. See "Create a Slack channel" below for the full flow.

Follow the Resource Creation Principles above — the catalog encodes signing schemes and service-specific behaviors for webhook channels.

Always pass an explicit name when creating a channel that has a user-visible identity (Slack --bot-name, Telegram bot name, etc.). Auto-defaults from the agent name are not reliable across orgs and surfaces — supply the flag yourself rather than letting it resolve server-side. For Slack specifically, this means passing --bot-name <display-name> on every valet channels create slack --agent ... and valet channels attach slack --agent ... call.

Browse the catalog

valet channels catalog
valet channels catalog get <name>

The catalog contains Valet-curated channel definitions for well-known services (GitHub webhooks, Slack Events API, Stripe, etc.). Each entry defines signing scheme, event taxonomy, and required secret slots.

Create from the catalog (preferred for webhooks)

valet channels create <entry> [--org <org>] [--agent <agent>] [--as <name>]

Creates a channel from the catalog. Use --as to rename the instance. If the catalog entry defines secret slots (e.g. WEBHOOK_SECRET), managed secrets are auto-generated and stored as secret-kind env vars. The managed field in the output is the secret name — use valet env set to rotate it.

Example:

valet env set GITHUB_WEBHOOK_SECRET=whsec_abc123 --org acme
valet channels create github-webhook --org acme

Attach / Detach

Attach an org channel to an agent. Use --events to filter which event types are delivered:

valet channels attach <name> [--agent <agent>] [--as <alias>] [--events <types>] [--bot-name <name>]
valet channels detach <name> [--agent <agent>] [--force]

For Slack channels, --bot-name sets the bot display name (defaults to agent name). After attaching, the CLI opens a browser for the Slack OAuth install flow and shows the bot name and workspace.

For Slack channels, detaching destroys the per-agent Slack bot. The CLI prompts for confirmation before proceeding. Use --force only after the user explicitly confirms the destruction.

Example:

valet channels attach github-webhook --agent my-reviewer --events pull_request,issue_comment
valet channels attach slack --agent my-agent --bot-name my-bot
valet channels detach slack --agent my-agent

Create a webhook channel

valet channels create webhook [name] \
  [--agent <agent-name>] [--org <org>] \
  [--verify <scheme>]

Verification schemes: hmac-sha256 (default), slack, stripe, svix, static-token, none. Key flags: --secret-name (name of an existing secret from valet env to use instead of auto-generating; required for slack, stripe, and svix), --signature-header (not used with slack or svix), --delivery-key-header, --delivery-key-path, --prompt. For hmac-sha256 and static-token, a managed secret is auto-generated if --secret-name is omitted. The slack scheme implements Slack's Events API signing protocol and handles url_verification challenges automatically. Run valet channels create webhook --help for full details.

The command prints the webhook URL, signing secret, and, when applicable, managed secret name. Report the URL and managed secret name. Do not repeat the raw signing secret in the response. Tell the user to copy it from their terminal output and store it securely. If command output is captured in the conversation, prefer --secret-name with a secret the user set in their own terminal so the command does not generate a new value.

Create a Slack channel

Slack is a two-step setup. Do both in order:

Step 1 — Once per org (prerequisite): create the org-level Slack channel. This authorizes Valet to create Slack apps in your workspace.

valet channels create slack --org <org>

The CLI prompts for a config token and refresh token (generate them at https://api.slack.com/apps under "Your App Configuration Tokens"), stores them encrypted, and records the workspace. There is exactly one org-level Slack channel per org — skip this step if the org is already connected (valet channels --org <org> will show a slack entry with the workspace name).

Step 2 — Once per agent that needs to be in Slack: create a per-agent Slack channel.

valet channels create slack [name] --agent <agent-name> [--bot-name <display-name>]

This provisions a dedicated Slack app for the agent, giving it a unique @bot-name in the workspace. If the org-level prerequisite is missing, the command errors and directs you to run Step 1 first. --bot-name sets the display name (defaults to agent name, resolved server-side). After creation the CLI opens a browser for the OAuth install flow, polls until install completes, and shows the bot name and workspace. Attaching an existing org's Slack to an agent (valet channels attach slack --agent <name>) is equivalent.

Run valet channels create slack --help for all flags.

Create a Telegram channel

valet channels create telegram [name] \
  [--agent <agent-name>]

Creates a Telegram channel and outputs a deep link (t.me/...) for connecting the bot. Run valet channels create telegram --help for all flags.

Create a heartbeat channel

valet channels create heartbeat [name] --agent <agent-name> --every 5m

Fires a prompt on a fixed interval. Run valet channels create heartbeat --help for all flags.

Create a cron channel

valet channels create cron [name] --agent <agent-name> --schedule "every day at 9am"
# Or with a raw crontab expression:
valet channels create cron [name] --agent <agent-name> --cron "0 9 * * *"

Run valet channels create cron --help for all flags (--timezone, --prompt, etc.).

List, inspect, destroy

valet channels [--org <org>] [--agent <agent>]
valet channels info <name>
valet channels destroy <name>

For Slack channels, valet channels shows the workspace name in the listing. Destroying an org-level Slack channel cascades — all per-agent Slack bots are destroyed first, then the org Slack connection is removed.

Environment Variables

Env vars are named values scoped to an org or agent, managed with the valet env command family. Every env var has one of two kinds:

• Secret (the default): credentials (API tokens, service keys, signing secrets) used by connectors and channels at runtime. The agent can invoke tools that depend on secrets but never sees the values — they flow through connectors and channels, not through the agent's environment, and list output masks them.
• Plain (--plain): configuration the agent should read directly — a region, a base URL, a customer identifier. Plain values are delivered to the agent's unix environment, readable as $NAME from bash and from code the agent writes, listed by name in the agent's system prompt, and displayed in list output.

Reference an env var of either kind in connector or channel configuration with {{NAME}} syntax. Names are unique per scope across both kinds, and a var's kind cannot be changed in place — unset it and set it again with the new kind.

Default to --org when setting env vars. Org-scoped env vars are available to every org-scoped connector and channel — and org-scoped plain vars reach every agent in the org — so one GITHUB_TOKEN or REGION serves every agent that needs it, and rotation is a single valet env set away. Use --agent only when an agent needs a different value for the same name (e.g., a distinct API key per agent); the agent-scoped var overrides the org-scoped one.

When an existing connector works but one agent needs different credentials, override the secret at the agent level — do NOT create a new connector. This is the canonical fix for any "the org-scoped token is wrong for this agent" situation: read-only org token vs. a read-write token for one agent, different tenant/account, narrower or broader scopes, separate rate-limit budget. Run valet env set <SAME_NAME>=<value> --agent <agent> and the existing org connector will pick up the agent-scoped value automatically. Spinning up a parallel connector is almost always the wrong answer — it duplicates configuration and forfeits the org-level catalog wiring.

NEVER ask the user for secret values within the LLM session. Direct them to run valet env set NAME=VALUE --org <org> in their terminal and wait for confirmation before proceeding. Plain values are not credentials — you may set those directly yourself.

Set env vars

valet env set <NAME=VALUE>... [--plain] [--org <org>] [--agent <agent>] [--no-wait]

Kind defaults to secret; pass --plain for values the agent should read from its environment. All vars in one invocation share a kind, and the command echoes the kind it applied (Set REGION (plain)). Scope follows the resolver: --agent / --org flags, then project link, then default org (org-scoped). Setting an env var triggers a redeploy so the change takes effect — agent-scoped changes redeploy that agent (the CLI waits for readiness; use --no-wait to skip), org-scoped changes redeploy the affected agents in the org. Reserved names (VALET_*, LD_*, PATH, HOME, and other runtime-owned names) are rejected for plain vars.

Give an agent configuration with a plain var:

valet env set REGION=us-east-1 --plain --agent my-agent

After the redeploy the agent reads $REGION in bash and in any code it writes, and the name appears in its system prompt.

{{NAME}} template syntax

Use {{NAME}} in connector --env, --header, or --url values to reference an env var of either kind. Templates are resolved at deploy time and can appear anywhere in a value:

--url https://{{DB_HOST}}/api
--header "Authorization=Bearer {{API_TOKEN}}"
--env SLACK_BOT_TOKEN={{SLACK_BOT_TOKEN}}

When directing the user to set secrets, always tell them what format the value should be in, including any prefix the service expects.

List and unset

valet env [--agent <name> | --org <name>]
valet env unset <NAME> [--agent <name> | --org <name>] [--force]

valet env lists the effective environment: each var's kind and scope, plain values inline, secret values masked, and an overrides org annotation when an agent-scoped var shadows an org-scoped one. Unsetting a referenced var fails with an error naming the dependent connector or channel. Use --force only after the user confirms those dependents may break.

Organizations

Organizations own agents, connectors, channels, and env vars. All agents belong to an org.

valet orgs create <name>           # Create a new org
valet orgs                         # List your orgs
valet orgs info <name>             # Show org details
valet orgs destroy <name>          # Delete an org
valet orgs members <name>          # List members
valet orgs invite <name> <email>   # Invite a member
valet orgs join <code>             # Accept an invitation
valet orgs leave <name>            # Leave an org
valet orgs remove <name> <email>   # Remove a member
valet orgs revoke <name> <email>   # Cancel an invitation
valet orgs set-default <name>      # Switch the default org

Org tips: The default org is set automatically when you create or join an org — you don't need --org on every command when targeting the default. Inside a linked project directory, the link's org takes precedence over the default (see valet topics resolution). Use valet orgs set-default <name> to switch the default after joining multiple orgs. Run valet orgs set-default --help for details.

Other Commands

Scaling

valet ps scale is how an agent's model is changed. There is no separate model command, and the manifest does not carry one — if the user asks to switch an agent to a different model, this is the answer.

valet ps scale agent=glm-5.2                 # Change model, keep the count
valet ps scale agent=0                       # Stop the agent, keep the model
valet ps scale agent=1                       # Start it again
valet ps scale agent=claude-sonnet-5:1       # Set both at once

Pass a single agent=<value> pair. The right side is a model ID, a process count, or model:count. Changing one preserves the other, so agent=glm-5.2 does not stop a running agent and agent=0 does not reset its model.

An agent's count is 0 or 1 today. There is no horizontal scaling of agents, so agent=2 is not a way to add capacity.

Run valet help ps scale for the current model list rather than quoting one from memory — the set changes, and a stale model ID fails the command.

Scaling bounces the affected containers so the new setting takes effect on restart. It is not a redeploy: the release is untouched.

Sites have no processes and cannot be scaled at all.

Sessions

Sessions persist conversation state so the user can disconnect and come back. Each valet console invocation writes to a session, and the same session can be resumed later or deleted.

Resume a session

valet console [-a <agent>] --resume <session-id>

Reopens the console on an existing session. The transcript is replayed locally and the agent continues where it left off. Use the session ID printed when the console started, or look it up via the dashboard. Without --resume, valet console starts a new session.

Delete a session

valet sessions delete <session-id> [-a <agent>]

Removes a session and its transcript. Destructive — confirm before running. Run valet sessions --help for the full session subcommand list.

Using valet exec

valet exec is the only way to run local commands with Valet-managed env vars injected. It fetches both kinds. Values live in the control plane, not in your local shell. After the agent exists, test secret-backed commands before treating its deployment as ready.

There are two modes:

Connector mode (no --)

The first argument is looked up as a connector name. If a command connector is found, its secrets are fetched and injected, and the connector's configured command is executed. Extra arguments are appended after the connector's configured args:

# Run the "gh" command connector (looks up connector named "gh")
valet exec -a my-agent gh pr list

# Use linked agent from current directory
valet exec gh pr list

Explicit secrets mode (with --)

Secret names are passed as a comma-separated positional argument before --. The command and its arguments follow after --:

valet exec [-a <agent>] SECRET[,SECRET...] -- command [args...]

Fetches the requested secret values and executes the given command with those secrets injected into the environment. The current process is replaced by the command.

# Run gh with GITHUB_TOKEN injected as an env var
valet exec -a my-agent GITHUB_TOKEN -- gh pr list

# Pass a secret as a CLI argument using {{}} syntax
valet exec -a my-agent API_KEY -- curl -H "Authorization: Bearer {{API_KEY}}" https://api.example.com

# Multiple secrets in one command
valet exec -a my-agent GITHUB_TOKEN,SLACK_TOKEN -- \
  sh -c 'test -n "$GITHUB_TOKEN" && test -n "$SLACK_TOKEN"'

Flag: --agent or -a: Agent that owns the secrets (uses linked agent if omitted). Run valet exec --help for full details.

Template syntax for CLI arguments

Use {{SECRET_NAME}} in command arguments to substitute secret values directly. This is useful for tools that accept credentials as flags or in URLs rather than reading from the environment. Works in both modes.

Running MCP servers locally

To test an MCP server that requires secret-backed environment variables:

valet exec -a my-agent SLACK_BOT_TOKEN,SLACK_TEAM_ID -- \
  npx -y @modelcontextprotocol/server-slack

Without valet exec, the MCP server would start without the required tokens and fail to authenticate.

Why valet exec is required

Regular shell commands (curl, npx, node, etc.) cannot access Valet secrets. This will not work:

# WRONG — $API_KEY is not set in your shell
curl https://api.example.com/data?key=$API_KEY

# CORRECT — valet exec injects the secret (explicit secrets mode)
valet exec -a my-agent API_KEY -- curl https://api.example.com/data?key={{API_KEY}}

# OR use connector mode if you have a command connector configured
valet exec -a my-agent my-connector-name

The same applies to any connector command. If its --command or --args reference secret-backed environment variables, test the exact command through valet exec before treating the deployment as ready.

Connector verification with valet exec

After the initial valet agents create deploy, test every command that requires secrets with valet exec. This catches authentication failures, wrong secret names, malformed URLs, and missing dependencies before you treat the deployment as ready. Deploy any resulting source fix before the end-to-end test.

What to test

Any connector command that references secrets in its --env flags should be verified locally. Reproduce the exact command the connector will run, wrapping it in valet exec:

# If the connector is defined as:
valet connectors create github-server \
  --transport stdio \
  --command npx \
  --args -y,@modelcontextprotocol/server-github \
  --env GITHUB_PERSONAL_ACCESS_TOKEN={{GITHUB_TOKEN}}

# Test the underlying command locally:
valet exec -a my-agent GITHUB_TOKEN -- \
  npx -y @modelcontextprotocol/server-github

For remote connectors (SSE/streamable-http) with secret-backed headers or URLs, test with curl:

# If the connector uses --header Authorization={{API_TOKEN}} --url https://mcp.example.com/mcp
# Test the endpoint is reachable and the token works:
valet exec -a my-agent API_TOKEN -- \
  curl -s -o /dev/null -w "%{http_code}" -H "Authorization: {{API_TOKEN}}" https://mcp.example.com/mcp

Do not test a webhook by sending an arbitrary request to a production endpoint. Use the provider's documented test-event flow or a dedicated test endpoint. If either action can trigger real work, get the user's approval first.

Verification checklist

Before running valet deploy, confirm:

1. All env vars are set: valet env --agent <name> and valet env --org <org> list every name referenced by connectors
2. Each conn

…(truncated)