Script.it

Your Script.it workspace, from the terminal — and from any coding agent.

Script.it turns a knowledge-work task into a script you can read, edit and depend on: describe what you want, connect the apps it needs, then run it on demand, on a schedule, or from a webhook. Your scripts run in an isolated cloud environment with your integrations already connected.

This CLI drives that environment from your machine.

Using this with a coding agent?

Give the agent the bundled Script.it skill first. It tells the agent how to authenticate, create a session, fetch its live instructions, and use every client-side command without copying product rules that can go stale.

Install the CLI and skill using the steps below, then tell the agent: Use Script.it.

Install

Before you start. Python 3.9 or newer, and a Script.it account — create one at script.it, or point the CLI at a self-hosted deployment with --api-url.

1. Install the CLI. It goes in its own isolated environment, so its dependencies never mix with a project's:

uv tool install git+https://github.com/script-it/cli.git

Installing from git while the package is pre-release; a pip install scriptit-cli will replace this once it is published.

# pipx — same isolation as uv tool
pipx install git+https://github.com/script-it/cli.git

# plain pip, into whatever environment is active
pip install git+https://github.com/script-it/cli.git

2. Check it landed.

scriptit version

3. Sign in. This opens your browser on an approval page: check it shows the same short code the CLI printed, approve, and the CLI finishes on its own. Your password never reaches the CLI — it stores a refresh token, plus the short-lived token it trades that for, at ~/.config/scriptit/credentials.json (mode 0600):

scriptit auth login

The browser never has to reach the machine the CLI runs on, so the same command works over SSH, in a container or in a hosted agent's terminal: where no window can open, open the printed link wherever you're signed in. The link carries nothing anyone else can sign in with, so it is safe to pass through a chat, and if the command is interrupted before you approve, running it again resumes the same link. When a coding agent runs this, the CLI prints the URL instead of opening a window — the agent's browser is not the one that would have opened. --no-browser forces that anywhere. For an on-prem deployment, add --api-url https://<your-deployment> — the CLI reads the auth mode from it and switches to a device-code flow by itself.

4. See what you have, then run one. skills list is the index of your scripts (alongside the platform's own skills); start takes a bare name from it and resolves it across your workspaces:

scriptit skills list
scriptit start <name-from-that-list>

5. Set up your coding agent.

Install the entry-point skill once, and any agent that reads skills knows how to drive your workspace.

In Claude Code, install it as a plugin — this repository is its marketplace:

/plugin marketplace add script-it/cli
/plugin install scriptit@script-it

claude plugin update scriptit@script-it brings it up to date, or turn on auto-update for the script-it marketplace under /plugin.

Codex installs the same plugin from the same marketplace:

codex plugin marketplace add script-it/cli
codex plugin add scriptit@script-it

Any other host that reads skills from a folder takes the file directly:

mkdir -p ~/.claude/skills/scriptit
curl -sSL https://raw.githubusercontent.com/script-it/cli/main/agent-skills/scriptit/SKILL.md \
  -o ~/.claude/skills/scriptit/SKILL.md

A host that reads only an AGENTS.md takes the file's contents pasted there. Use it from a coding agent explains what the skill does and why it stays this small.

Keeping it current, and removing it

uv tool upgrade scriptit-cli
uv tool uninstall scriptit-cli

Logging out forgets the stored credential without uninstalling anything:

scriptit auth logout

Why you might want it

• Work on your automations with a coding agent. Point Claude Code, Codex or Cursor at your Script.it workspace and let it read, write and run your scripts. That is what this CLI was built for — see Use it from a coding agent.
• Stay in the terminal. Run a script, tail its logs, check a trigger, move a file, without switching to the browser.
• Let an agent show you its work, not just describe it. scriptit auth browser-url --next <path> prints a one-time link that opens straight to a script or run in the app, already signed in. An agent with a browser you can see opens it there itself — so when it finishes something you watch the block tree and its outputs come up instead of reading a paragraph about them. The link lends this machine's login, lives 60 seconds and works once; you get an email whenever one is used from somewhere new.
• Script your scripts. The commands this client answers speak --json, so you can wire Script.it into whatever you already automate with.

How it works

The CLI is a thin remote client. Commands you type run in your Script.it environment, not on your machine:

scriptit (your machine)
  │  Bearer <token>                     (scriptit auth login)
  ▼
Script.it  ──►  your isolated environment  ──►  your script, your integrations

Nothing automation-related runs locally. No scripts execute on your machine, and your integration credentials are never copied to it. Everything you run lands in a real session you can watch live in the Script.it app — the same view your teammates see.

Connect

Install covers signing in. Beyond that, keep several accounts or deployments side by side as named profiles:

scriptit auth login --api-url https://scriptit.internal.example --profile work
scriptit auth use work
scriptit auth status

Use

scriptit start weekly-report          # run a script
scriptit logs <run-id>                # ...and read what it did
scriptit trigger list                 # what fires it, and when
scriptit integrations list            # what it can reach
scriptit describe --concepts          # the full platform reference
scriptit describe --system            # agent-ready runtime context

Run any shell command in your environment:

scriptit exec -- ls /workspaces
scriptit exec --timeout 300 -- pytest -q
scriptit exec --cwd /workspaces/<workspace-id> -- ls

--timeout is enforced where the command runs, so it exits 124 there rather than outliving a client that stopped waiting.

Move files both ways:

scriptit exec -- ls /workspaces/<workspace-id>
scriptit fs push ./report.csv /workspaces/<workspace-id>/assets/report.csv
scriptit fs pull /workspaces/<workspace-id>/logs/run.log .
scriptit fs read data_files/report/output.html

A relative remote path starts where exec runs, in the session's directory, so a path that works in exec names the same file in fs.

Sessions

Every command runs inside a session — the same kind of conversation the in-app agent works in, and you can watch it live in the app. A session is sticky: it persists across commands and across shells until you start another.

scriptit session current              # which session am I on, and why
scriptit session new                  # start a fresh one
scriptit context                      # fetch this session's agent instructions
scriptit session use ses_abc123       # reattach to an earlier one
scriptit session list                 # recent sessions

The session has its own directory, and that directory is the working directory for every command you run. Your workspaces are mounted inside it, so a script at /workspaces/<wid>/my-script is also workspaces/<wid>/my-script from where commands land. It is a mount, not a copy — anything you change is immediately visible in the app and to every other session. data_files/ is the session's own scratch space.

To run one command in a different session without disturbing the sticky one:

SCRIPTIT_SESSION=ses_abc123 scriptit exec -- ls

That is also how an agent harness gives each task its own transcript.

Machine-readable output

Add --json to any of auth, context, fs, session, sandbox or version. stdout becomes exactly one JSON document, and everything else — progress, prompts, warnings, errors — goes to stderr, so you can pipe stdout straight into a parser:

scriptit sandbox status --json | jq -r '.sandboxes[].state'
scriptit context --json | jq -r '.skills'

On failure the document is {"error": "..."} and the exit code is non-zero — including when the argument parser is the thing that rejected the command, so there is no case where stdout comes back empty.

auth login --json still opens a browser and prints its progress, but to stderr; the document it returns is the resulting login. fs read is the one exception: it writes the file's bytes unmodified, so --json is accepted and ignored rather than promising a document it will not produce. exec likewise streams the command's own output. Forwarded commands pass --json through to Script.it, which decides what it means.

Which commands are which

This client answers auth, context, exec, fs, session, sandbox and version itself. Everything else is forwarded — start, status, logs, wait, validate, describe, trigger *, integrations *, skills *, … — and answered by Script.it.

That is deliberate: the platform stays the single source of behavior, so a feature added there works through the client you already have. No upgrade needed, and no command list here to fall out of date.

scriptit --help covers the local commands; scriptit describe --concepts covers the structured platform reference, and scriptit describe --system renders that runtime knowledge for agent context.

Use it from a coding agent

One file — agent-skills/scriptit/ — installed into the agent host once, as the Claude Code or Codex plugin or as a plain skill file; Set up your coding agent above has the commands.

The skill carries almost no platform knowledge on purpose. It creates a fresh session, then runs scriptit context to fetch one complete live bundle of runtime guidance, product behavior, external-agent workflow, authoritative app links, connected integrations, and current skills. The workstation client only transports and prints that bundle, so agent behavior is updated with the platform instead of being copied into each CLI release.

Good to know

• Sessions run one command at a time. A second command queues rather than interleaving; the client waits for you.
• Paused environments wake automatically. Any command resumes yours and waits until it is ready, so there is nothing to start by hand.
• V2 output is read in full, in pages. Commands stay readable in the app, and their actual exit codes reach your terminal. The saved transcript preview can be shorter than the output returned to the CLI. Older v1 environments use a separate compatibility path that recovers output beyond their SSE text cap.
• V2 event connections can reconnect. The client resumes from its last event cursor without submitting the command again. Missing output or an unconfirmed result is reported as an error, never success.
• No interactive shell. Commands are dispatched fire-and-forget and their lifecycle is observed through an event stream, with no channel for stdin — so scriptit exec -- vim cannot work. Use one-shot commands, or the app.
• Update notices, not auto-update. The client checks at most once a day, in the background, and prints one line to stderr when a newer release exists. SCRIPTIT_NO_UPDATE_CHECK=1 silences it.
• Anonymous usage analytics, opt-out. Command names and exit codes, never their contents or arguments. DO_NOT_TRACK=1 turns it off.

Exit codes

Environment variables

Contributing

Issues and pull requests are welcome — see CONTRIBUTING.md for setup and the one architectural rule this repo keeps.

Security

Found a vulnerability? Please report it privately through GitHub's Report a vulnerability form rather than opening an issue — see SECURITY.md.

License

Apache-2.0