What “local” means for an AI coding-agent workspace
Local should name a data path, not create the impression that an agent model lives inside your laptop. Crowsnest keeps the workspace and history operations on-device while the installed agent runtimes retain their own provider connections.
Crowsnest runs its interface on 127.0.0.1 and does not upload transcripts, prompts, answers, project paths, conversation titles, usage counts, crash reports, or product telemetry. Browsing, search, repair, and Insights operate on local records. Claude Code and Codex still contact their providers when you run a model. The official app has a narrow account sign-in/refresh path, and Pro Remote Workspaces use an SSH connection you explicitly open to your own machine.
“Local” has to answer three different questions.
Privacy claims become slippery when storage, control, and model execution are collapsed into one word. A useful definition asks where history is read, where the interface listens, and who receives a prompt when new model work begins.
- History plane: Crowsnest reads Claude Code transcripts from local files and Codex history through the locally installed Codex app-server protocol.
- Control plane: the Crowsnest server binds to loopback, so its browser or native shell connects to 127.0.0.1 rather than a hosted Crowsnest workspace.
- Model plane: Claude Code and Codex remain the runtimes that contact Anthropic, OpenAI, or another configured provider when you ask a model to work.
Crowsnest is local in the first two senses. It coordinates the third; it does not replace provider models with on-device inference and does not proxy their model traffic.
History operations stay on the machine that owns the records.
The everyday workspace—gallery, folder browser, full-message search, reader, local usage evidence, and supported transcript repair—operates over history already available on the machine. Claude edits rewrite only the supported target line, retain every untouched line byte for byte, and create recoverable backups and an audit record. Codex reads and native fork/retry operations go through app-server rather than through a hosted Crowsnest service.
Crowsnest's own indexes and caches stay in application-owned local storage. Operations bundles deliberately exclude transcript text, prompts, assistant answers, artifacts, credentials, and host paths. The core server has no analytics, crash reporting, public-host mode, or update-check call.
That distinction matters: local history can still contain secrets. Keeping it off a new hosted index removes one copy and one operator from the trust chain; it does not make the underlying transcript harmless.
Your coding agents still use their provider networks.
Starting or continuing a Claude Code or Codex conversation sends the chosen prompt and necessary context through that runtime's configured provider path. Anthropic's documentation explicitly describes Claude Code as a local program that sends prompts and model outputs over the network for model interaction. OpenAI documents Codex app-server as the interface rich clients use for authentication, conversation history, approvals, and streamed agent events.
Crowsnest does not intercept or re-label that traffic as local. Provider terms, retention, training controls, enterprise settings, alternate model backends, and runtime telemetry remain provider concerns. When Crowsnest builds a cross-provider or cross-account briefing, the text is composed locally; the receiving provider sees it only when the local operator confirms and starts the new session.
“No transcript upload to Crowsnest” is therefore the accurate promise. “Nothing ever leaves the laptop” would be false during live model work.
The application has two narrow outbound paths of its own.
Account sign-in and refresh
When the official app has an account endpoint configured, sign-in sends credentials and refresh runs near session expiry. Neither request includes transcript content, prompts, project paths, titles, models, usage, or error reports. A valid cached entitlement is verified locally and keeps working offline.
Remote Workspaces over SSH
Pro can open one hardened, non-interactive SSH session to a strict destination the local operator entered. It uses existing SSH authentication, stores no key or password, installs no package, opens no forwarding, and runs a checksum-verified helper over standard input and output.
A source checkout or uvx crowsnest ships with no account endpoint configured, so the account path is unreachable there. Remote Workspaces stay disconnected until the local operator chooses Connect. Remote paths remain opaque to the browser, and the remote machine never hosts the Crowsnest web interface.
The optional agent browser is another explicit capability worth naming: it is off until a browser tool is called, uses a dedicated profile rather than the local operator's personal browser, and allows read-only navigation, snapshots, screenshots, and evaluation. A page loaded by that browser can make ordinary page requests; this is not transcript synchronization or an invisible background crawler.
Loopback limits reachability; it does not isolate same-user processes.
Binding to 127.0.0.1 prevents another machine from reaching the server through a LAN interface. It does not make the server a sandbox. Software running under the same operating-system user may already be able to read ~/.claude, start local requests, inspect process state, or modify project files.
Crowsnest adds narrower defenses inside that reality: filesystem reads and writes are confined to known roots and allowlists; transcript writes use active-file and stale-version interlocks; preview hosts reject non-loopback origins; browser file URLs are refused; Codex private storage is not treated as a public API; and remote working directories stay behind connection-scoped opaque references.
If the threat model includes malicious local software running as your account, use operating-system isolation, a separate user, a virtual machine, or a dedicated development machine. A loopback address cannot solve a compromised local identity.
The website and the installed product have separate analytics boundaries.
The installed Crowsnest product has no analytics or product telemetry. This public website offers optional GA4 analytics only after a visitor explicitly opts in. Before consent, it loads no Google script, makes no Google request, and sets no analytics cookie; declining leaves page-load resources first-party. The preference can be changed from the website privacy page.
Website measurement never makes a product transcript available to the site. Keeping the two policies separate avoids using a true product claim to hide a different website behavior.
Evaluate any “local AI workspace” with concrete questions.
- Where does the interface bind?Ask for the exact address and whether a public-host switch exists.
- Where is history read?Local files, a supported local protocol, a vendor cloud, or a new synchronized index are materially different answers.
- Which process sends model prompts?Name the installed runtime and provider instead of treating all network traffic as one application.
- What calls happen while idle?Account refresh, telemetry, crash reports, update checks, polling, and remote synchronization should each be stated separately.
- What is the same-machine threat model?Loopback, filesystem confinement, a sandbox, and operating-system user isolation solve different problems.
First-party data-flow documentation and product boundaries
Provider references: Anthropic's Claude Code data-usage guide and OpenAI's Codex app-server guide. Crowsnest's loopback binding, filesystem and protocol rules, account exchange, browser boundary, SSH transport, website consent behavior, and honest limitations were checked against the released product and landing-page source on September 9, 2026.
Published and boundary-reviewed September 9, 2026. Provider data practices can change independently; linked first-party documentation and the provider settings attached to your account are authoritative.