From nothing to a cross-CLI handoff
This page starts with an empty machine and ends with a task that you send from one CLI to a different CLI. Each step gives the command and the result that you must see. If a step does not agree, stop at that step.
1 · What you must have first
The list is short. Everything after it is optional.
- Go 1.25 or later, to build Glider. The module declares
go 1.25.0, and an older toolchain refuses it. - A C compiler, on Windows only. The tray and the native
window bind to Win32, so
cgois required and a build withCGO_ENABLED=0fails. Any gcc is sufficient: MSYS2 UCRT64, or TDM-GCC. Linux needs no compiler. - A minimum of one AI coding CLI:
claude,cursor-agentoragy. Two or more give you the handoff. - Windows or Linux.
Make sure that each CLI operates by itself first:
go version gcc --version # Windows only claude --version cursor-agent --version agy --version
What you do not need for a handoff
A handoff to another CLI needs none of the following. Each one belongs to a different part of Glider, and you can add it later.
| Not needed for a handoff | What it is for |
|---|---|
| A certificate | Only MITM and transparent mode decrypt traffic. A handoff sends nothing through TLS that Glider reads. |
| Ollama, or any local model | Only routing a turn to your own machine. Refer to step 9. |
| Administrator or root | Only transparent redirection. Refer to step 4. |
| WinDivert, or iptables | Transparent redirection, on Windows and on Linux in that order. |
| The WebView2 Runtime | Only the dashboard in a window of its own, on Windows. Windows 11 has it. Without it, the dashboard still opens in a browser at 127.0.0.1:8081. |
| Docker | Only the GitHub MCP server over stdio. The HTTP transport needs no Docker. |
2 · Build Glider
git clone https://github.com/singhutsav5502/Glider cd Glider go build -o glider.exe ./cmd/glider
Run Glider from the repository root. It reads
configs/glider.yaml and
configs/vendor_candidates.yaml from the current directory.
3 · Start it
The default config turns transparent redirection on. Therefore Glider gets the traffic of each CLI with no change to any of them. On Windows, start the terminal as Administrator. On Linux, use root.
.\glider.exe
You must see these lines:
dashboard http://127.0.0.1:8081 gateway http://127.0.0.1:8080/v1
Open the dashboard. If the Vendors page is empty, push Rescan for CLIs. Glider must find each CLI that you installed.
Trust the certificate, or transparent mode fails. The first start makes a
CA at ~/.glider/mitm/ca.crt. Glider decrypts with it, and a CLI refuses that
traffic until the certificate is in your trust store. Install it there: on Windows this is
Trusted Root Certification Authorities. Claude Code needs only this. For
Cursor, also point its runtime at the same file:
NODE_EXTRA_CA_CERTS=%USERPROFILE%\.glider\mitm\ca.crt, then stop Cursor
completely. Refer to MITM · the certificate authority.
Delegation and the workspace command below do not need the certificate. Only interception needs it. To do the walkthrough with no certificate, use the gateway in step 4.
4 · If you do not want Administrator
Transparent mode needs Administrator or root. Without it, use the gateway instead: point one CLI at Glider and start Glider with no special permission.
# Claude Code set ANTHROPIC_BASE_URL=http://127.0.0.1:8080 # any CLI with a base-URL setting http://127.0.0.1:8080/v1
Everything below this point operates the same in the two modes. Refer to MITM & interception for the full comparison.
5 · Tell Glider your project directory
A delegate CLI must know which directory to use. Glider asks you one time for each session. Reply with the path and the flag:
. /workspace
Glider asks each session, also when you set a default. It cannot see which project a new CLI is in, therefore it does not estimate. A default on the Vendors page of the dashboard puts that path in the question, and you send it back. Thus a second CLI that you open in a different project never gets the directory of the first project with no message.
6 · Your first handoff
Type this in any supported CLI. Put the name of a different CLI at the end of the message.
summarize the last ten commits /cursor-agent
Glider claims the message, runs cursor-agent, and puts its
final answer in your session. You do not open a second window.
The flag must be at the end. If you put
/cursor-agent at the start, your own CLI reads it as a local
command and never sends the message. Refer to
Delegation for the cause.
7 · Answer a permission question
A delegate CLI stops when it needs a permission. Glider gives you the question and a token:
[claude] needs permission for 1 action it could not complete headlessly: - Edit: src/auth/session.ts Reply with "4472bef1 /claude:allow" to approve and continue, or "4472bef1 /claude:deny" to skip this step.
Send the token back. The run continues with that one permission only:
4472bef1 /claude:allow
The token identifies the run and the vendor. Glider gives it to you, and you must not write your own token. When the run completes, Glider shows the edits as a diff.
8 · Templates: another way to run a CLI
Add :name after the vendor to select a different command
template. These are the templates that
configs/vendor_candidates.yaml gives you:
| Vendor | Default | Other templates |
|---|---|---|
claude | headless | :interactive |
cursor-agent | headless | :interactive |
agy | interactive | :headless, :interactive |
fix the auth bug /claude:interactive refactor this module /agy:headless
An interactive template opens the native session of that CLI in a new window, with your task as the first message. You then control that window, and no text comes back to your chat. A headless template runs the CLI with no window and returns the final answer to you.
/agy opens a window, because the default template of agy is
interactive. Its headless mode cannot ask you for a permission, so it
always fails at the first permission. Use /agy:headless
only when you accept that limit.
9 · Send a turn to your own machine
This is a different mechanism from the handoff, and it is optional. Glider can send a turn to a local model instead of the cloud.
ollama serve ollama pull qwen2.5-coder:14b
Choose a model that fits your card. Glider reads the true
size of your GPU when it starts, and it refuses a model that cannot fit. It
does this in about a tenth of a second, and it names the cause, instead of
letting Ollama fail with a CUDA error half a minute later.
qwen2.5-coder:14b above estimates 9000 MB and wants about a
12 GB card. On a 4 GB card, use qwen2.5-coder:3b and set
local_model to it. The VRAM page shows the measured total and
the headroom. With no nvidia-smi on the machine, Glider reports
VRAM as not measured and stops limiting local models, rather than inventing
a size.
Then use a routing command. It can go at any position in the message:
| Command | Result |
|---|---|
/local or /fast | Sends this turn to your machine |
/cloud or /heavy | Sends this turn to the cloud |
| no command | The rule ladder decides |
/local explain what this function does
To use only local models, start Glider with the pure local profile. Then Glider uses no cloud key at all.
.\glider.exe --config configs\glider.local.yaml
Refer to Routing for the full rule ladder, and to Pure local for the profile.
10 · Watch what it does
Open http://127.0.0.1:8081. These are the eight pages:
| Page | What it gives you |
|---|---|
| Overview | Each request, with the rule that claimed it and the cause |
| VRAM & Models | The GPUs and the models that Glider found. You can load a model, remove a model, and give a GPU to a model. |
| Rules Engine | The routing rules, and a test that shows which rule a message obeys |
| MCP | The MCP servers, their tools, and the connection to GitHub |
| Vendors | The CLIs that Glider found, the default workspace, and the reply format |
| Workspace | The files under runs/ that a tool wrote, and a comparison of two of them |
| Playground | A safe place to try the commands. It runs no CLI. |
| Config | The full config. Glider applies most changes immediately. Refer to the reference. |
Start on the Playground page. It examines what you type with the same parser that Glider uses, and it changes nothing.
11 · Each command in one table
| You type | Result |
|---|---|
<task> /claude | Runs the task in Claude Code |
<task> /cursor-agent | Runs the task in Cursor Agent |
<task> /agy | Opens Antigravity in a window with the task |
<task> /agy:headless | Runs Antigravity with no window |
<task> /claude:interactive | Opens Claude Code in a window with the task |
<token> /claude:allow | Gives one permission and continues the run |
<token> /claude:deny | Refuses the permission and continues |
<path> /workspace | Sets the directory for this session |
/local · /cloud | Selects the model for this turn |
12 · When something is wrong
| What you see | The cause |
|---|---|
| "Unknown command: /agy" | The flag is at the start. Move it to the end. |
| Glider asks for a workspace each time | Set a default on the Vendors page. |
| The Vendors page is empty | Push Rescan for CLIs. |
| Transparent mode catches nothing | Start Glider as Administrator, and do the discovery first so it has the process names. |
| A delegate call needs 20 seconds or more | This is the start time of the other CLI. Glider adds no time limit. |
| The reply is a long JSON transcript | The reply format is "raw". Set it to "clean" on the Vendors page. |
| A TLS error, or "self-signed certificate" | The CA is not in your trust store. Refer to step 3. For Cursor, also set NODE_EXTRA_CA_CERTS, and stop the program completely. |
| Transparent mode catches a process that you do not want | It selects by the name of the image, therefore it catches each process with that name. Send the PIDs that you want to POST /api/mitm/enrollment. |
Next: Automatic rules makes your CLI send these tasks without your help, Delegation gives the full permission relay, and Architecture shows where each part operates.