The usual end of a coding agent session: the app runs on localhost, the agent says "you can now deploy this", and the human goes off to create an account somewhere, click through a dashboard, and paste credentials back. The agent that wrote everything is the one participant that can't finish the job.

This post walks through a Claude Code session on Specific where that last step is also the agent's. The same flow works in Cursor, Codex, or any agent that can run a terminal.

The session

1. Install the CLI. It installs a binary on your machine, so our instructions tell the agent to check with you first:

curl -fsSL https://specific.dev/install.sh | sh

2. Connect the agent. In the project directory:

specific init --agent claude

This appends usage instructions to CLAUDE.md and allows specific docs and specific check in .claude/settings.local.json, so the agent can read documentation and validate config without a permission prompt each time. For Cursor it writes .cursor/rules/specific.mdc; for Codex and others, AGENTS.md.

From here the prompt is just "deploy this".

3. The agent writes the infrastructure. Specific has no SDK; the agent declares what the app needs in specific.hcl and the app reads plain environment variables. For a Node web app with a database:

build "web" {
  base    = "node"
  command = "npm run build"
}

postgres "main" {}

service "web" {
  build   = build.web
  command = "node dist/server.js"

  endpoint {
    public = true
    health_check {
      path = "/healthz"
    }
  }

  env = {
    PORT         = port
    DATABASE_URL = postgres.main.url
  }

  dev {
    command = "npm run dev"
  }
}

The agent didn't guess this format from training data. specific docs ships the documentation inside the CLI binary, so what it reads always matches the installed version.

4. Validate and run.

specific check
specific dev

specific check catches config mistakes before anything runs. specific dev starts a local Postgres and the service, with a local dashboard on localhost:3000 showing logs and the database. If the agent is running on a machine you can't browse from, specific dev --tunnel gives every public service a *.tunnel.spcf.app URL so it can show you the app.

5. The agent registers itself.

specific login --agent

No browser opens and nobody signs in. The CLI registers as an agent through WorkOS agent registration, and the platform creates a provisional account for it on the spot. The command prints what that account is:

Registered this CLI as an agent. No login needed to deploy.

This account is UNCLAIMED:
  - it can hold one project on the free tier
  - it and everything deployed to it are deleted at 2026-10-10T14:03:11Z
    unless a person claims it before then

Forty-eight hours, one project, then gone. That is the whole trust model: an unclaimed account can do useful work but cannot accumulate anything.

6. Deploy.

specific deploy

The CLI archives the project and uploads it. The platform provisions the managed Postgres, builds the image, rolls the service out behind the health check, and prints the public URL. If specific.hcl declared secrets that have no value yet, the deploy pauses and asks for them, so the agent can hand that question to you rather than invent values.

✓ Deployed successfully

  deployment: depl_...

  URLs:
    web: https://<generated-name>.spcf.app

7. Hand the account to a person. When you're happy with what's running:

specific claim --email [email protected]

The CLI prints a link. You open it, sign in (or sign up) with that email, and the page shows a short code. Give the code back to the agent:

specific claim --code ABCD-EFGH

Claimed. This account and its projects now belong to [email protected].
They can manage everything at https://dashboard.specific.dev.
This CLI keeps working as their agent.

If you're new, the provisional organization becomes your personal one. If you already have an account, the project moves into one of your organizations and the throwaway is deleted. Either way the agent's credentials keep working, now on your behalf, and the 48-hour clock stops.

What the agent can and cannot do

Unclaimed, the agent can create one project on the free tier and deploy to it as often as it likes. It cannot create a second project; the CLI tells it to claim the account first. When the deadline passes unclaimed, every project is deleted the same way a dashboard delete would be, and then the provisional user goes.

Some things stay yours regardless of who holds the account:

Approving the install. Our instructions ask the agent to check with you before running it.
DNS. For a custom domain, the CLI prints the records; you add them at your registrar.
Production management in the dashboard: scaling, secret rotation, domain removal, billing.

Why it works this way

Every other deployment path assumes a human at a browser somewhere in the loop. Agents increasingly run where there is no browser: a cloud sandbox, a CI job, a headless box someone talks to over chat. Making the agent a first-class identity, with a bounded scope and a hard expiry, lets it finish the job without anyone handing it long-lived credentials. The claim step is the moment a person takes responsibility for what was built, and it is designed to take under a minute.

Common questions

What if the 48 hours pass?

The account and its deployments are deleted. Your code is untouched, so the agent runs specific login --agent and specific deploy again and you're back in a few minutes.

Does this work with Cursor or Codex?

Yes. specific init --agent cursor or --agent codex writes the instructions in the right place, and the rest is the same CLI.

Can a human log in without a browser too?

Yes. specific login and specific deploy support a device-code flow: the CLI prints a link and a code, and specific login --device-code <code> completes it.

Is it really free?

The unclaimed account is on the free tier. After claiming, the project stays on whatever plan you choose in the dashboard.

Try it

Paste this into Claude Code, Cursor, or Codex in a project directory:

Help me get started with Specific by following: https://docs.specific.dev/for-ai/onboarding

Or install the CLI yourself:

curl -fsSL https://specific.dev/install.sh | sh

For more, see the coding agents guide, the Quickstart, and the OpenClaw setup for fully headless agents.