How-To · 7 min read

Let Claude Code Check and Lock Your Staging Environment With MCP

Lockit Team · 2026-10-03

AI coding agents now run the same commands engineers do: build, migrate, deploy to staging, run the integration suite. That raises an obvious question. When your colleague has locked staging for a QA pass, does the agent know?

Usually not. The agent sees your repository and your terminal. It doesn't see the chat channel where people say "I'm on staging until 3". So it deploys, and someone's test run is gone.

Lockit's MCP server closes that gap. Once connected, Claude Code can list your shared resources, see who holds each one and until when, lock a resource before using it, and release it afterwards. This guide covers the setup, permissions, and the project instructions that make the agent actually use it.

Claude Code commands and behaviour below are from Anthropic's Claude Code documentation as of 2026.

What you need

  • A Lockit workspace on a paid plan. The MCP server, like the REST API, is part of Starter and above. See pricing.
  • An API key. In Slack, open Lockit's App Home tab and click "Create API Key". The same key works for the REST API and the MCP server.
  • Claude Code installed.
  • Your shared environments set up as Lockit resources, for example staging and staging-db. Create them in Slack with @Lockit new.

The MCP server

SettingValue
URLhttps://api.lockitbot.com/api/locky/mcp
TransportHTTP
Auth headerAuthorization: Bearer <your-lockit-api-key>
Optional headerX-Lockit-User: you@company.com

X-Lockit-User tells Lockit which member of your workspace the agent is acting for. Set it to your own email so a lock the agent takes appears under your name in @Lockit list, and takeover requests come to you.

Adding it to Claude Code

The quickest way is one command. Put the key in an environment variable first so it doesn't end up in your shell history:

export LOCKIT_API_KEY=...   # from Lockit's App Home tab

claude mcp add --transport http lockit https://api.lockitbot.com/api/locky/mcp \
  --header "Authorization: Bearer $LOCKIT_API_KEY" \
  --header "X-Lockit-User: you@company.com"

By default, claude mcp add uses the local scope: the server is available in the current project only, for you only, and stored in ~/.claude.json. Use --scope user to make it available in all your projects.

Note that claude mcp add doesn't validate credentials. A wrong key is accepted and only fails when Claude Code connects.

Sharing it with your team via .mcp.json

To give everyone on a repository the same setup, use the project scope, which writes to .mcp.json in the project root. Don't commit the key itself. Claude Code expands environment variables in .mcp.json, including in url and headers, so each developer supplies their own:

{
  "mcpServers": {
    "lockit": {
      "type": "http",
      "url": "https://api.lockitbot.com/api/locky/mcp",
      "headers": {
        "Authorization": "Bearer ${LOCKIT_API_KEY}",
        "X-Lockit-User": "${LOCKIT_USER}"
      }
    }
  }
}

Each developer sets LOCKIT_API_KEY and LOCKIT_USER in their shell profile. If a variable isn't set, Claude Code still loads the config but warns and uses the literal ${VAR} text, so the connection will fail with an auth error until it's set.

Claude Code asks for approval before using servers from a project's .mcp.json the first time, which is a sensible safety step for anything checked into a repository.

Checking the connection

From your shell:

claude mcp list
claude mcp get lockit

claude mcp list shows each server's health. If Lockit shows "Failed to connect" with a 401, the key in the header is wrong or missing. Inside a Claude Code session, /mcp shows the same information.

The tools Claude gets

ToolScopeWhat it does
lockit_list_resourcesreadEvery resource with status, holder and lock end time
lockit_get_resourcereadOne resource, with description and default lock length
lockit_lock_resourcewriteLock a resource. Duration minutes, hours and days are added together
lockit_release_resourcewriteRelease a lock
lockit_create_resourcewriteCreate a resource
lockit_delete_resourcewriteDelete a resource; its creator is told in Slack
lockit_set_resource_default_durationwriteDefault lock length for one resource
lockit_set_workspace_default_durationwriteWorkspace-wide default lock length

If the key has read scope, only the two read tools are available. That's a good starting point if you want the agent to check before deploying, but not to take locks itself.

Permissions: allow reads, confirm writes

You probably want Claude to check staging freely, but to ask before it locks or releases anything. Claude Code permission rules name MCP tools as mcp__<server>__<tool>. In .claude/settings.json:

{
  "permissions": {
    "allow": [
      "mcp__lockit__lockit_list_resources",
      "mcp__lockit__lockit_get_resource"
    ]
  }
}

Lock and release calls still prompt you. Once you trust the workflow, you can add mcp__lockit__lockit_lock_resource and mcp__lockit__lockit_release_resource to the allow list. Leave delete and the default-duration tools out; those are admin actions a person should do deliberately.

Telling Claude when to use it

Connecting the server gives Claude the ability. Project instructions give it the habit. Add a short section to the repository's CLAUDE.md:

## Shared environments

Staging and the staging database are shared with the team and coordinated in Lockit.

- Before deploying to staging, running migrations, resetting data, or running the
  integration suite against staging, call lockit_get_resource for `staging`
  (and `staging-db` for anything touching the database).
- If it is locked by someone else, stop and tell me who holds it and until when.
  Do not deploy.
- If it is free, lock it with lockit_lock_resource for 1 hour, then proceed.
- When finished, or if the task fails, release it with lockit_release_resource.

The "if the task fails" line matters. Agents, like CI pipelines, tend to stop at the first error, and an unreleased lock blocks your teammates until it expires.

What it looks like in practice

With the server connected and the instructions in place, a session goes something like this:

You: Deploy this branch to staging and run the smoke tests.

Claude: (calls lockit_get_resource for staging) Staging is locked by priya@company.com until 15:30 UTC. I haven't deployed. Do you want me to wait, or should you ask Priya for a takeover?

Or, if it's free:

Claude: (calls lockit_lock_resource for staging, 1 hour) Locked staging for 1 hour. Deploying… Smoke tests passed. (calls lockit_release_resource) Released staging.

When the agent's lock is refused because someone else holds the resource, the tool result says so, and the instructions tell Claude to stop rather than push ahead.

Your teammates see the agent's lock exactly like any other in Slack: @Lockit list shows staging held by you, and they can click "Alert when released" or "Ask for takeover". The takeover request comes to you, because the agent was acting as you.

Other clients

The same server works with other MCP clients that support remote HTTP servers with custom headers.

Cursor reads .cursor/mcp.json in the project or ~/.cursor/mcp.json globally, and uses ${env:NAME} for environment variables:

{
  "mcpServers": {
    "lockit": {
      "url": "https://api.lockitbot.com/api/locky/mcp",
      "headers": {
        "Authorization": "Bearer ${env:LOCKIT_API_KEY}",
        "X-Lockit-User": "you@company.com"
      }
    }
  }
}

VS Code works too. Note that VS Code's own configuration format uses a top-level servers key rather than mcpServers, so adapt the snippet above.

Claude.ai custom connectors aren't supported yet, because the Lockit MCP server doesn't offer OAuth. Use Claude Code or another client that accepts a header.

The full server reference is in the MCP section of the docs.

MCP or the REST API?

They do the same things. Use MCP when an AI agent is doing the work interactively, and the REST API when a pipeline is. A CI job deploying main to staging should call the API directly in a lock step and release in an always-run step; how to lock a staging environment from your CI/CD pipeline has GitHub Actions and GitLab CI examples. For the broader approach, see how to manage shared staging environments.

FAQ

Does the agent need its own Lockit account?

No. It uses your API key, and with X-Lockit-User set to your email, its locks show up as yours. That's usually what you want: you asked it to do the work, so you're the person a teammate should talk to.

Can I stop the agent from locking anything at all?

Yes. Use a read-scope key, which only exposes the list and get tools, or leave the lock and release tools out of your Claude Code allow list so every call needs your approval.

What if the agent locks staging and then crashes?

The lock lasts for the duration it chose, so it clears on its own. Keep durations short in your CLAUDE.md instructions, an hour or less for a deploy and smoke test, and release manually from Lockit's App Home tab if you notice a leftover lock.

Does this work as a Claude.ai custom connector?

Not as a Claude.ai custom connector, because those need OAuth, which the Lockit MCP server doesn't support yet. It works with Claude Code, Cursor and VS Code.

Stop asking who's on staging.

Add Lockit to Slack in a minute. Free for your first 2 resources.