Can I get a shell on a build server that has no inbound SSH?

Yes. The agent connects outbound, so the runner needs no open ports. Your AI client runs commands on it through the relay, which is ideal for ephemeral or locked-down runners.

Developers & cloud

Debug CI runners & build servers live

Q: How do I debug a flaky build on a self-hosted CI runner?

Install the AI Commander agent on the runner and ask your AI client to inspect the workspace, re-run the failing step, and read the output by quoting the runner's session code. You debug on the exact machine the build ran on, instead of guessing from log artifacts.

Q: How is this different from an AI cloud sandbox?

A cloud sandbox gives the AI a fresh, throwaway environment. AI Commander gives it a shell on your real CI runner — the one with your caches, toolchain versions, and the failing state — which is what you need to reproduce a build problem.

The build is green on your laptop and red in CI. Instead of pushing "debug" commits and squinting at log artifacts, AI Commander lets Claude open a real shell on the actual runner — inspect the workspace, re-run the failing step, clear a poisoned cache — and tell you what differs.

The job

Self-hosted runners and build servers are often the hardest machines to reach: ephemeral, locked down, no inbound SSH. Yet "works on my machine" bugs live precisely in their environment — toolchain versions, env vars, caches, disk. AI Commander gives an AI client a shell right there:

Re-run the failing command and read the real error, not a truncated log.
Compare versions: node -v, python --version, cc --version.
Inspect and clear caches that went stale: ~/.cache, node_modules, build dirs.
Check whether the runner simply ran out of disk or memory mid-build.

What it looks like

Claude Code — MCP

You: the build on runner-3 fails at the test step — reproduce it and find why Claude: > cd /actions-runner/_work/app && npm ci npm warn: lockfile out of sync > node -v v18.19.0 (laptop: v20) Claude: The runner is on Node 18 while you build on Node 20, and the lockfile is out of sync — that's the test failure. Bump the runner's Node or pin it in CI.

Why AI Commander for CI debugging

	AI Commander	Debug commits	SSH-into-runner	AI sandbox
The real runner state	✓	slow loop	✓	fresh env
No inbound port	✓	✓	✗	✓
Interactive	✓	✗ commit→wait	✓	✓
AI client drives it	✓ MCP	✗	✗	SDK

Set it up

On the runner / build host (Linux), install the agent:

curl -fsSL https://aicommander.dev/install | sudo bash

Connect your AI client, quote the session code (or alias runner-3), and start debugging on the real thing.

FAQ

How do I debug a flaky build on a self-hosted runner?

Install the agent on the runner and ask your AI client to inspect the workspace, re-run the failing step, and read the output by quoting the runner's session code. You debug on the exact machine the build ran on, not from log artifacts.

Can I get a shell on a build server with no inbound SSH?

Yes. The agent connects outbound, so the runner needs no open ports. Your AI client runs commands through the relay — ideal for ephemeral or locked-down runners.

How is this different from an AI cloud sandbox?

A sandbox gives the AI a fresh, throwaway environment. AI Commander gives it a shell on your real runner — with your caches, toolchain, and the failing state — which is what reproducing a build problem requires.

Debug where the build actually ran

Install the agent on your runner and let Claude reproduce the failure on the real machine.

Install the agent Connect your AI client