The pixel station is the permission model, not a skin
StarNet makes a strange promise and mostly explains it in concrete terms. A room is a capability-scoped team, a hallway authorizes a handoff, and an object grants a tool. Move those pieces around the pixel-art station and you change the agent harness underneath. The screen projects actual sidecar state, including active work, agent movement, costs, schedules, and completed files. It is meant to make invisible agent boundaries visible.
Each agent gets its own workspace, transcript, memory, persona, tools, and permissions. Several can run concurrently, with results passed back to an orchestrator conversation. Tasks can arrive through Telegram, Discord, Slack, Signal, or Matrix, and MCP servers can add more capabilities. Finished files land in an outbox instead of remaining buried in chat. These are real model and tool calls, so a charming animation can still spend money or modify files.
A 3,365 MB checkout changes the cost of trying from source
Our clone at commit 7ee93ce contained 43,200 files and about 663,386 lines of source. It occupied 3,365 MB before npm installed anything. Installation took 41 seconds, added 93 packages, and used another 1,598 MB. This is a very large checkout for a desktop agent app, even though its npm dependency count is modest. Storage, backup, antivirus scanning, and clean-clone CI all inherit that size.
The simplest source path avoids most of the desktop stack. StarNet says its Node sidecar uses core modules and can start with node sidecar/index.js, then serves a local interface on port 8787. Node 18 or newer is required, with Node 22 matching CI. Building the Tauri desktop shell adds Rust and operating-system prerequisites. Our harness found no generic build script, so it skipped the build rather than substituting a desktop command.
What happened when we ran it
Our sandbox installed 93 packages in 41 seconds and used 1,598 MB. There was no build script or target, so no build ran. The test command ran for 71 seconds and exited with code 1. Node's test summary recorded 5 passed and 0 failed out of 5. Npm audit reported 0 known vulnerabilities across critical, high, moderate, and low severities.
The last supplied log lines show named checks passing, including credential redaction, failure classification, concurrent probes, browser consent, file-approval arguments, model settings, and delayed rating or memory behavior. They do not show a failed assertion or an error explaining the final exit code. The only defensible conclusion is that the overall command did not pass in our fresh Node 22 container, despite the passing Node test summary. We cannot assign a cause from that excerpt.
The repository has 11 CI workflow files and a tests directory, but no Dockerfile. Those signals fit a desktop product with platform release gates rather than a container service. They also make the unexplained exit worth reproducing before changing core code. A green subset and a zero-vulnerability audit are useful evidence; neither converts an exit code of 1 into a successful suite.
Version 0.12.4 supports two desktop families and excludes Linux
StarNet v0.12.4 was published on September 20, 2026. The main repository was pushed on September 23, and GitHub listed 212 stars with 19 combined issues and pull requests on September 24. The public download track supplies Windows x64 plus separate Intel and Apple Silicon macOS images. Linux packages may exist as internal artifacts, but the install guide says Linux is not a supported public target.
The release process requires Windows signatures and timestamps, macOS Developer ID signatures and notarization, plus signed updater artifacts. The documentation correctly separates pipeline requirements from proof that one downloaded copy ran on your machine. Users are told to stop when the publisher or Gatekeeper result is wrong rather than bypass the warning. That is unusually sober installer advice for an early desktop agent project.
Local-first still sends task content to the model you choose
The sidecar keeps station state and workspaces on the machine, while prompts and relevant content go to the selected model provider. Ollama can keep model traffic local on port 11434. OpenRouter, OpenAI, Anthropic, Google, and other configured providers receive requests when used. Connected chat platforms and web tools also contact their own services. Local-first here describes control and storage defaults, not an offline guarantee.
The privacy document gives the necessary uncomfortable detail. Transcripts, run and cost history, agent memory, channel history, and voice cache are plaintext. Desktop provider keys and some bot tokens use the OS keychain, while Spotify and several provider sign-in tokens remain plaintext files. Bare sidecar mode can also fall back to plaintext bot-token storage. Anyone with access to the operating-system account may be able to read the work product.
Two open bugs hit the exact provider paths many users will try
Issue 20 describes Ollama runs finishing with 0 tool calls although the interface listed filesystem tools. The reporter reproduced it with two local models and said direct Ollama tool calling worked outside StarNet. Issue 24 describes OpenRouter BYOK succeeding for direct requests while delegated agents stop on an out-of-managed-credit message before reaching OpenRouter. These reports concern different paths and do not prove every installation is affected.
They do identify the trial you should run first. Give one agent a disposable workspace and ask it to write, read, and report one file. Then delegate the same bounded task to a second agent and confirm the provider receives it. StarNet earns attention because its spatial interface could make multi-agent authority easier to inspect. The 3,365 MB checkout, failed lab command, and provider-path reports mean that proof should come before a real project, not after it.