Ghostget gives your AI agent named web actions: read a page, archive one media item, or use a connected account, without credentials or a browser to steer. It is free, MIT licensed, and runs on macOS and Linux beside the agent you already use, such as Codex, Claude Code, or Cursor.
Latest release: v0.18.38. Install it with Bun from the GitHub Release named in the getting-started guide, then read a public page with ghostget read https://example.com. You need no account, API key, or connected service for that first step.
Ghostget was previously named Wrench. The migration guide in the repository keeps existing local state in place.
An agent in your accounts, without your browser
Suppose you want your agent to look through your Gmail contacts, find a thread in Beeper, and draft a reply for you to send. The quick way is to hand the agent a signed-in browser. That browser can do anything you can do in every tab it can reach: open settings, send a message to the wrong person, or post twice after a slow page load. You would be trusting the agent's plan, and the plan never shows you the exact thing it is about to send.
Ghostget gives your agent named actions. gmail contacts.list is one action. Sending a Beeper message is a sequence you can review: find the conversation, read recent context, preview the exact message bubbles, then confirm. Your agent never receives your passwords, tokens, cookies, or an open browser. Each signed-in call is tied to one service, one of your accounts, and one reviewed definition of what the action sends and returns, so Ghostget never borrows whatever session happens to be open.
Who it is for, and who should use something else
Ghostget is for a person who runs an agent on their own computer and wants it to work with ordinary web pages and their own accounts, such as Gmail, Beeper, WhatsApp, LinkedIn, and X. Which actions exist differs by service: the Gmail actions only read, and WhatsApp can be read but not sent to. It suits work where you want to see the message or post before it goes out, and where a duplicate would be a real problem.
If you need an agent to explore an arbitrary site, click through a checkout, or fill in a form Ghostget has no action for, use browser automation. If you are building your own agent, Ghostget supplies no model, planner, or chat interface; your agent brings those. Ghostget is designed to sit beneath browser automation, API clients, and MCP servers and to work alongside them.
Ghostget is for accounts and material you are authorized to use. It does not bypass sign-in, payment, access controls, or DRM, and installing it grants no access to any account. You connect each one yourself, through the service's own sign-in or consent page.
What runs today
On 2026-09-24 the source tree listed executable actions for 21 services, including Gmail, Beeper, WhatsApp, LinkedIn, X, Reddit, GitHub, and YouTube. The supported services page lists every action for the current release and how each one connects.
Start by installing the service definitions bundled with your release, then see what is installed. The second command prints the Gmail actions and the inputs each one needs:
ghostget adapter sync-bundled --json
ghostget capabilities gmail
Gmail connects through Google's official Gmail and People APIs. You download a Google OAuth desktop client file, Ghostget opens Google's consent page in your browser, and you approve it there. Ghostget never asks your agent to copy or print the token. The three Gmail actions list contacts, list threads, and read a thread; none of them changes your mailbox. Google's consent still grants read access to the whole mailbox.
ghostget auth login gmail-main --client-file /absolute/path/client_secret.json
ghostget gmail contacts.list --auth gmail-main \
--input '{"collection":"contacts","limit":1,"include_stats":false}' --json
Every write that matters starts as a preview
Ghostget sorts actions by risk. A read changes nothing. A small, normally reversible change is one step up. A visible or consequential change, such as sending a message or publishing a post, is the highest level Ghostget will run, and a class above that is blocked.
Anything above a read produces a short-lived preview first. The preview shows the service, the account, the input, any attachments, and what will be sent. Your agent can prepare it; nothing is sent until someone passes that preview's digest to the confirm step:
ghostget confirm <preview-digest> --json
For messaging, the preview is a draft only. It shows the recipient and each message bubble in order, and sending needs a fresh request made for that turn after the draft has been reviewed.
A write with an unknown result is not sent again
A post can reach the service while the reply is lost on the way back. Ghostget records each consequential write before it goes out. If the result is unknown, the write stays marked as unresolved, and Ghostget will not send it again or try another route. It stays that way until separate evidence, such as reading the post back or your own review, shows what happened. One narrow exception exists for a post made through a signed-in web session: you can create a new request that names the original attempt and explicitly accepts the risk of a duplicate. The original stays marked as unresolved.
When a service changes a page, a field, or an account check, the affected action stops and waits for review instead of guessing. Pages and media you saved stay on disk, and exact copies of account reads stay encrypted on your machine.
Your own message history, exported for your own use
Ghostget can export your Beeper history as a local message bundle in the Message Like Me format. The exporter checks records against that format, and it states whether the export is complete for the window it read, cut short, or of unknown completeness. Products built on Ghostget lists what uses these exports, including Textbutler (formerly Message Like Me), which imports them.
A published list of what is checked
Ghostget keeps a register of its own claims. Each entry states one property, names the check that covers it, lists the conditions it assumes, and says what it leaves unverified. On 2026-09-24 the register held 244 claims: 180 evidenced by checks that run in CI, 45 planned, and 19 not verified. The register's own check fails when the published summary goes stale or when a maintainer rule has no matching entry.
Two entries show the range. The rule that a write with an unknown result is never re-sent is checked against a formal model of the send process, and runs recorded from the real code are replayed against it. The rule that a write needs a matching preview before it runs has example tests, but its stateful model is still planned. What Ghostget's checks cover, claim by claim walks through the register.
Where it is going
The intent is for Ghostget to be the small, reviewed layer between an agent and a person's accounts: the agent plans, and Ghostget runs only named actions that someone has reviewed. Each new service would arrive as reviewed actions with their own previews and records, so an agent's reach grows one named action at a time. The planned entries in the claims register show the next checks the maintainers intend to add. They are plans, and they carry no dates.
Status and limits
The claims register itself says what it does not cover: how third-party services behave, the correctness of Bun, the operating system, GitHub, npm, and Vercel, hostile plugin code, and hostile programs running as the same user on your computer. Nineteen claims have no automated check. Fifteen of them, about repository and hosting settings, rest on an administrator reading those settings back.
Not everything Ghostget stores is encrypted. The Gmail refresh credential, for example, sits in a file only your user account can read, and it is not encrypted at rest; keep Ghostget's state out of shared backups. Some services need their own local tool or OAuth client before Ghostget can connect, and account setup on Linux runs through the command line only. A sent message counts as submitted to the service; Ghostget does not claim it was delivered.
For how Ghostget compares with agents that drive a browser directly, read browser-using personal agents compared. For why running an agent inside a virtual machine does not answer the same question, read VMs cannot contain agents.