@playcode/cli

The Playcode command line. Sign in once through the browser, then every command acts as you: list projects, read and run things on a project's computer, publish. It is the door a laptop agent such as Claude Code walks through - it runs shell commands natively, so nothing more is needed.

npm install -g @playcode/cli      # or: npx @playcode/cli <command>

playcode login                    # Sign in with Playcode: a code to type in the browser, allow the CLI in one workspace
playcode whoami
playcode projects                 # your projects, with the uid and the name each one answers to
playcode vm ls my-shop /srv/app   # files on the project's computer
playcode vm cat my-shop /srv/app/.env.example
playcode vm exec my-shop -- npm run build     # a background job, streamed, exit code returned
playcode vm cp ./dist my-shop:/srv/app/dist   # upload; the reverse downloads
playcode vm shell my-shop         # an interactive shell
playcode publish my-shop --wait   # deploy, then wait for the publish to land

Every management operation, without a command being written for it:

playcode domains                          # the family's operations
playcode domains domainUpdate --help      # the arguments, from the registry
playcode domains domainUpdate --uid 8a3... --input '{"autoRenew":true}'
playcode webhooks webhookEndpointCreate --workspaceUid ws... --input @endpoint.json
playcode events eventSearch --workspaceUid ws... --filter '{"types":["domain.*"]}'

Families: domains, projects, events, webhooks, consent, tokens, api. Values are plain strings, JSON when it parses, @file.json to read a file. A consent-marked operation takes --proposalId from proposalCreate.

Every command takes --json for machine-readable output. A project is named by its uid or by the name it answers to on the web.

playcode login asks Playcode for a code, shows the page to open and waits: you type the code, confirm it is the CLI you started, and allow it in one workspace - the projects family by default (--permissions projects:vm,domains:write asks for more). The sign-in refreshes itself and lives in ~/.config/playcode/credentials.json (mode 600); playcode logout takes it back everywhere, as does Revoke on Settings > Workspace > Developers. CI and a scripted agent sign in with an access token instead: playcode login --paste, playcode login pc_..., or PLAYCODE_TOKEN. The origin defaults to https://playcode.io (PLAYCODE_ORIGIN or --origin to change it); an origin behind Cloudflare Access takes CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET.

What a sign-in may do is decided when it is made - the CLI can never widen it. A refusal names the permission it would have needed.

vm exec takes one shell line after --, quoted as for ssh: playcode vm exec my-shop -- 'npm test && npm run build'.

MCP

playcode mcp serves the API to an MCP client on stdio, over the same token: four tools, search_operations (what you want to do, in words), describe_operation (the arguments as a JSON schema), read_operation and write_operation (a name and plain JSON arguments; the model never sees GraphQL). Claude Desktop, Cursor and Claude Code register it as a command:

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

The credential comes from playcode login (the browser sign-in refreshes itself, so the server runs for weeks) or PLAYCODE_TOKEN; what it may do was decided when it was made, and a refusal names the permission it lacked.

Contributors: pnpm test runs the unit tests; pnpm test:smoke:cli:dev (from the repository root) walks the built binary against a real environment with a real token (test/smoke, fail-closed without one).