Connect your coding assistant

Let your coding assistant inspect, diagnose, and operate your Ghosty apps directly — no copy-pasting.

Your coding assistant (Claude Code, Codex, Cursor, or any tool that supports MCP servers) can talk to the Ghosty platform directly: list your apps, read deploy history and logs, ask Ghosty to diagnose a failure — and then act on it: deploy the fix, put work on a preview link, store a secret, roll back a bad release.

The Ghosty CLI ships this as a built-in tool server. It runs on your machine, uses the same sign-in as the CLI, and can only see and do what you can.

Set it up

Install or update the Ghosty CLI: npm i -g ghosty-cli@latest (it needs Node.js 20 or newer).
Sign in: ghosty login. It prints a link and a short code — see below.
Get your app's code onto this computer: ghosty clone <app> — see below.
Register the tool server with your assistant. The command is ghosty mcp — it speaks over stdio.

Your assistant can do all of this for you. Ask it to set up Ghosty, and it runs these commands itself — you only approve the sign-in.

Sign in with a link and a code

ghosty login doesn't need a browser on the computer it runs on, so it works the same in a terminal, inside a coding assistant, or on a remote machine.

Run ghosty login. It prints a line like this and waits:

To sign in, open https://console.whiteghost.ai/connect/device?code=BCDF-GHJK and approve "my-laptop" (code BCDF-GHJK). Waiting…

Open the link. You land in the White Ghost console, where you're already signed in (if not, sign in first).
Check that the code on the page matches the one in your terminal, then click Approve. If you belong to more than one workspace, pick the one this computer should use.
The command finishes on its own: Signed in to <your workspace> as <you>.

Only approve a request you just started yourself. If you don't recognise one, click Deny — nothing is connected.

Run ghosty login from inside an app folder and the console suggests that app's workspace. To suggest a specific one, add --company <workspace>.

When your assistant runs the sign-in, it shows you the same link and code and waits for you to approve. ghosty login --json prints them as a first line for tools:

{"event":"device_code","url":"https://console.whiteghost.ai/connect/device?code=BCDF-GHJK","user_code":"BCDF-GHJK","expires_in":600}

The request expires after 10 minutes. The link and the code are safe to show: approving always needs your own signed-in console and a click.

The approve page

The link opens Connect your assistant in the White Ghost console. It shows what is asking to connect, so you can check it before you approve:

The code, in large type. It must match the code your assistant showed you. If it doesn't, click Deny.
The computer: its name, its system (for example macOS or Windows), the assistant running the sign-in (Claude Code, Codex, or a terminal) and the version of the Ghosty CLI.
When it asked: how many minutes ago the request started.
Which workspace, if you belong to more than one. The workspace your assistant asked for is picked for you; you can choose another. There's no choice to make if you have one workspace.

Nothing happens until you click. Approve connects the assistant to the workspace you picked, as you: the page says "Done — go back to your assistant", and the assistant finishes signing in on its own. Deny closes the request and nothing is connected.

If you open the console without a link, go to /connect/device and type the code instead.

The page tells you when there's nothing to approve:

This request expired: requests last 10 minutes. Run ghosty login again.
This code isn't valid any more: it was already used or mistyped. Run ghosty login again for a fresh link and code.
No workspace yet: an assistant connects to a workspace of your own. Finish setting one up first.
The workspace is getting assistant sign-in soon: cancel the sign-in in your assistant and run ghosty login --browser instead.

Get an app's code: `ghosty clone`

ghosty clone expense-tracker
cd expense-tracker && ghosty dev

ghosty clone <app> puts the app's code in a new folder named after the app (or pass --dir <folder>; it must be new or empty). It works for every app you own or collaborate on:

If the app's code lives in a code repository and git is installed, you get a full copy with its history, ready for ghosty deploy.
If git isn't installed, or this computer doesn't have access to the repository yet, you get a download of the code instead.

ghosty clone --json reports where the code went: {"ok":true,"dir":"…","via":"git"} (or "download").

Register the tool server

Claude Code — every Ghosty app folder already includes a .mcp.json file that registers the tools. The first time you open Claude Code in the folder, approve the ghosty server when it asks. Anywhere else:

claude mcp add ghosty -- ghosty mcp

Codex

codex mcp add ghosty -- ghosty mcp

Cursor (and most other tools) — add to the MCP configuration file:

{
  "mcpServers": {
    "ghosty": {
      "command": "ghosty",
      "args": ["mcp"]
    }
  }
}

Run your assistant from inside an app folder and the tools automatically target that app; from anywhere else, the assistant passes an app name explicitly.

Look and diagnose

Tool	What it does
`diagnose_app`	Asks the Ghosty platform to diagnose why an app is failing. Returns a verdict, a plain-language explanation, and step-by-step fix instructions your assistant can act on. Counts toward the app's daily diagnosis allowance.
`list_deploys`	Recent deploys: status, time, commit, deploy id.
`get_deploy_log`	The full build & deploy log for one deploy.
`get_app_logs`	Recent production logs from the live app.
`get_app_state`	Each platform piece the app needs (repository, service, database, URL) and whether it's ready.
`list_apps`	The apps in your workspace and what each one can do.
`whoami`	Who is signed in and which apps they own.
`sign_in`	Starts signing in from inside the assistant: returns the link and code to show you, and finishes on its own once you approve.
`preflight`	Checks your machine and connection are ready.
`list_secrets`	The names of an app's secrets and the environment variable each binds to. Names only — secret values are never shown.

Act

Tool	What it does
`deploy_app`	Ships the app in the folder: saves the changes and the platform builds and deploys them, reporting progress until live.
`create_preview`	Puts the current work on a private preview link without touching the live app.
`redeploy_app`	Rebuilds and redeploys from the latest shipped code, without new changes.
`rollback_app`	Puts a previous successful version back live (no rebuild; stored-data changes are not undone).
`set_secret`	Stores a secret for the app and binds it to an environment variable.
`create_migration`	Applies a stored-data schema change to the builder's personal dev data.
`init_app`	Scaffolds a new Ghosty app into an empty folder.
`provision_app`	Creates or syncs everything the app needs on the platform from its configuration.
`connect_app`	Requests a connection to another app's capability (a workspace admin approves when needed).
`delete_app`	Permanently deletes an app (the code repository is kept).

Safety

Deleting is guarded. delete_app refuses unless the assistant passes the app's exact name as a separate confirmation — the same type-to-confirm the console uses. A mismatch deletes nothing.
Secret values only go in, never out. set_secret accepts a value but no result — success or error — ever contains it, and no tool can read a stored value back.
Your sign-in, your apps. The server runs locally with your CLI sign-in; every action carries exactly your permissions, and each app folder is tied to its own workspace so an action can never land on a same-named app somewhere else.
Canceling is safe. If you stop the assistant mid-action, work already accepted by the platform finishes there (a build keeps building), but nothing new is started after the cancel.

A typical moment

A deploy fails. Instead of pasting logs around, you say: "my expense-tracker deploy failed — find out why and fix it." Your assistant calls diagnose_app, gets the verdict and fix instructions from the platform, applies the code change, and calls deploy_app — you watch it go live.

Signed-in devices

Every computer and assistant you've approved is listed in the console under Settings → Signed-in devices:

Column	What it shows
Device	The computer's name and system.
Workspace	The workspace it's connected to.
Assistant	Claude Code, Codex, or a terminal, and the Ghosty CLI version.
First seen	When you approved it.
Last seen	When it last worked on your apps.

Revoke signs one of them out. It takes effect within a minute, and that computer has to run ghosty login (and get your approval) to connect again.
Sign out all devices does the same for every one of them, in every workspace.

A connection lasts 90 days, then that computer runs ghosty login again. Signed-out and expired connections stay on the list for a while, marked as such.

Troubleshooting

"You're not signed in" — run ghosty login in a terminal (or ask your assistant to), open the link it prints, approve, then ask the assistant to try again.
The link opens but there's nothing to approve — the request expired (after 10 minutes) or was already used. Run ghosty login again for a fresh link and code.
"Your workspace is on an older platform version" — your workspace is getting this sign-in soon. Until then, ghosty login --browser signs in through a browser on this computer.
"This email doesn't have access to that workspace" — you approved with an account that isn't a member of the workspace you picked. Ask a workspace admin to add you, or pick another workspace.
ghosty clone says there's no app you can work on — check the name with ghosty apps. If the app is someone else's, ask its owner to add you as a collaborator.
"Diagnosis isn't available on this workspace yet" — your workspace is getting this feature soon; deploys, logs, and state already work.
An assistant you don't recognise is on the list — click Revoke next to it under Settings → Signed-in devices (or Sign out all devices), then approve only the sign-ins you start yourself.
The server doesn't appear in the assistant — check the CLI is on your PATH (ghosty --version) and restart the assistant after registering.