Using clanker.engineer from CLANKER.NET

CLANKER.NET and clanker.engineer are two projects that work side by side. CLANKER.NET is where you develop: your pod, your editor, your coding agents, every day. clanker.engineer is where agents run work for your team: agentic CI/CD and the agent files (skills, agents, workflows) your workspaces hold. They are separate; a replicator stands up your own environment and never one of ours. This page is how a developer’s pod reaches clanker.engineer, and what the person at the keyboard controls.

Where	What happens there
CLANKER.NET	Everyday development: your pod, your repositories, the app’s chat, your coding agents
clanker.engineer	Agentic CI/CD, and the agent files and runs of your workspaces; the thing your coding agents call into

What a pod gets

One clanker server in every agent configuration of the pod (Claude Code and Codex both read it), and one key per developer behind it. That key is delegated to the developer’s own coding agents by their own consent, and it covers a set of workspaces chosen once, when it is made: not one key per workspace, and not one server per workspace.

The server is declared in the repository’s dev-container file, the same place every other agent server is declared (the dev-container file, agents.http):

"customizations": {
  "replicator": {
    "env": { "optionalSecrets": ["CLANKER_API_KEY"] },
    "egress": {
      "proxy": {
        "secrets": [
          {
            "name": "CLANKER_API_KEY",
            "hosts": ["clanker.engineer", "*.clanker.engineer"],
            "headers": ["Authorization", "x-api-key"],
            "require": true,
            "perDeveloper": true
          }
        ]
      }
    },
    "agents": {
      "http": [
        {
          "name": "clanker",
          "url": "https://clanker.engineer/mcp/",
          "bearer": "CLANKER_API_KEY",
          "connect": {
            "scopes": ["apikey:pod"],
            "mintUrl": "https://clanker.engineer/api/v1/api-keys/pod",
            "revokeUrl": "https://clanker.engineer/api/v1/api-keys/pod"
          }
        }
      ]
    }
  }
}

The server is wired from the first provision, connected or not. Until a developer connects, the pod’s outbound proxy refuses its requests and sends nothing on.

Skills shared with pods

An owner or admin of a workspace can share library skills with the workspace’s pods. While a developer’s key is connected, each of their pods copies the shared skills into its shared agent files (/workspace/.claude/skills/ce-home--<slug>/) within about a minute, keeps them read-only, updates them when the library changes and removes them when they are no longer shared. A pod installs skills; shared agents are listed in /workspace/.claude/library.status and not installed. The pod syncs the workspace the key was made in. How it works and its limits: the dev-container file, “Shared library skills in a pod”.

Connect and disconnect

A developer connects from the app, in Settings, in one pass:

Connect on the clanker entry. If you are not signed in to clanker.engineer, you sign in, and the request resumes where it was.
clanker.engineer shows what your pod’s agents are asking for, as a request, with the workspaces you can choose to give them.
Accept. You land back in Settings, where the entry now says connected, which account it is, and which workspaces it covers, with a link to manage them.

Nothing is typed, copied or pasted, and nothing is registered ahead of time: the app finds clanker.engineer’s sign-in from the server’s address.

Disconnect in the same place. The key is revoked at clanker.engineer and removed from the pod, and the very next request from any agent is refused. Connecting again replaces the connection.

Where the key lives

Not in your pod’s members. A member holds only a stand-in token; the real key is held by the pod’s outbound proxy, which swaps it in on the way out to clanker.engineer and to no other host. A coding agent, a shell command or a build script in a member cannot read it, and it is in no environment file, log or image.

The pod’s network container watches the coordination server for your connections. When one is made, changed or removed, it hands the new value to the proxy and tells the proxy to reload. No member is restarted, and no open connection is dropped; a connect is live within seconds, and a disconnect takes effect on the next request. Your host owner can also seed a key for you by hand (replicator secrets set CLANKER_API_KEY --developer <login>); it stands only while nothing is connected, and a connection wins over it.

One key, many workspaces

You may belong to several clanker.engineer workspaces. The key covers the ones you chose at consent, and each call says which one it means:

list_workspaces lists the workspaces the key may act in: the id, the name, your role, which one is the default, and the repositories each is linked to.
workspace, an optional argument on every other tool, names the workspace to act in.
A call that names none acts in the workspace linked to the repository the agent is working in, and otherwise in the default one. A workspace is linked to a repository by its owner or an admin, in that workspace’s settings. The link only chooses a default among the workspaces the key already covers; it never adds one.

The list is read live on every call. If you leave a workspace, it drops out of the key at once; it is not copied onto the key when you accept.

A workspace’s owners and admins can approve CLANKER.NET’s app for that workspace, within the permissions they allow. For a developer in that workspace the consent step is skipped for it: the workspace is simply included. Everything else about the key is unchanged. Withdrawing the approval removes the workspace from every key that held it.

Narrow it, or take it back

The key is bounded by the permissions you accepted: it can do no more than those, whoever is asking, and it ends with the connection. In clanker.engineer, Settings, Agents lists each connection with the workspaces it covers. There you can:

narrow it to a subset of its workspaces (the default one stays). A key never widens here: adding a workspace is a new consent;
revoke it, which removes every workspace at once. Connecting again from the app’s Settings makes a new one.

Disconnecting from the app’s Settings does the same from CLANKER.NET’s side.

Run a workflow from the chat

In a conversation of the app, the Run on clanker.engineer… action (the play button beside the message box) starts one of your clanker.engineer as you. A sheet lists the workflows your workspace holds there, asks for the input the chosen one takes, and Run starts it. A message in the conversation (in the thread, when you started it from one) says “Started on clanker.engineer” with a link to the run, written by you like any message of yours.

It uses a separate connection from the pod’s key, with its own consent: the first time, the sheet sends you to Connect (the same flow as in Settings), and clanker.engineer asks you to allow two things, reading your workflows (library:read) and running them (workflow:run), and to stay signed in for you (offline_access). That connection is listed in Settings as “used by this app on your behalf”. It is kept on the coordination server and used only there: your pod never receives it, no agent in it can use it, and the pod’s key does not gain a single permission from it. Disconnect it in Settings, or take the consent back in clanker.engineer under Settings, Agents.

A few limits worth knowing:

Runs happen in the workspace you chose at the consent, and spend that workspace’s credits as any run does. A missing subscription or credits comes back as that message, not as a failed run.
You can start at most ten runs every ten minutes.
If the connection no longer allows running workflows, the sheet asks you to connect again.

The connection is one more line of the same server’s declaration in the dev-container file (connect.app, see the dev-container file):

"connect": {
  "scopes": ["apikey:pod"],
  "mintUrl": "https://clanker.engineer/api/v1/api-keys/pod",
  "revokeUrl": "https://clanker.engineer/api/v1/api-keys/pod",
  "app": [
    {
      "name": "clanker-chat",
      "label": "clanker.engineer",
      "scopes": ["library:read", "workflow:run", "offline_access"],
      "appUrl": "https://app.clanker.engineer"
    }
  ]
}