Agent and local runtime

Studio is one app on your machine, but it is two processes. The Electron renderer is the user-facing surface — windows, tabs, Copilot, the editors. The Go sidecar is everything that needs to talk to your network at low level: SSH, Telnet, RDP, VNC, serial, packet capture, ARP scanning, SNMP, ONVIF, LLDP/CDP discovery, plus the local knowledge graph and the local embeddings model. This split exists for two reasons. Performance: Go runs protocol code well, has a tight memory footprint, and uses BoringCrypto for FIPS-grade primitives. Safety: the renderer never directly touches your network at the protocol layer or holds plaintext credentials at the moment of authentication. Both responsibilities live in the sidecar, which has a smaller and more auditable surface. This page describes that architecture, the local data it owns, and the boundary it maintains with the cloud.

​

The two processes

The two communicate over a localhost loopback bound to the parent’s process group. The sidecar will not accept connections from anything but the parent process.

​

What lives on your machine

The pattern: local-first by default, uploaded only when you ask.

​

Why a Go sidecar at all

Three properties make this worth the architectural complexity:

• BoringCrypto. The Go agent links against a FIPS-validated cryptographic module via Go’s GOEXPERIMENT=boringcrypto build mode. AES-256-GCM, the algorithm protecting your record envelopes, runs in a validated module rather than in JavaScript.
• Protocol surface. Real SSH (with TACACS+, jump hosts, legacy crypto, key-based auth), real RDP (CredSSP, MCS/BER, framebuffer decompression), real serial (with break sequence) are not what JavaScript is for. Go’s network and crypto libraries are mature and well-audited.
• Plaintext containment. The renderer never holds the plaintext of a Keychain credential. The sidecar unwraps the DEK, decrypts the credential, hands it to the protocol library, and discards the plaintext when the protocol no longer needs it. The renderer sees only references and approval prompts.

​

Local embeddings and search

Studio’s semantic search runs on a local embeddings model. When you save a memory, write a procedure, or have a conversation, the sidecar produces a vector embedding and stores it in the local index. When you search (Mod+K or a Copilot retrieval call), the query vectorizes locally and matches against the local index. This means:

• The full-text content you search against does not leave your machine for retrieval.
• Search works offline, even when the network or AWS is unavailable.
• The embeddings model itself is small enough to ship inside the application; no model download required.

The match results may then be sent to Bedrock as part of the next prompt’s context. That’s the line: retrieval is local; reasoning over retrieved content uses the model. This is also where Studio’s value compounds. Every conversation, memory, procedure, host, and diagram your team produces becomes part of a knowledge graph and an embeddings index built specifically against your network’s vocabulary, your customers, your sites, your equipment, your incidents. The longer you use it, the more accurate the retrieval becomes for your work — not generically, for yours. That graph is encrypted under your organization’s keys, indexed against your local content, and irrelevant to any other workspace. It’s not portable to another tool because it’s not separable from the connective tissue Studio builds around it.

​

Network discovery and capture

The sidecar can do everything you’d expect from a competent network engineer’s toolkit: ICMP, traceroute, DNS lookup, ARP (active and passive), LLDP / CDP, SNMP get / walk / bulk, banner grab, DHCP discovery, STP topology observation, packet capture, NetFlow collection. These all run with the operating system’s networking privileges — the user’s permissions on the user’s workstation. Three things to be aware of:

• No discovery without explicit invocation. The sidecar does not background-scan your network. Discovery runs because you (or a Copilot tool call you approved) asked for it.
• Privilege required for some operations. ARP-level work, packet capture, and some SNMP modes need elevated permissions on most operating systems. Studio prompts the OS to grant them; we do not silently elevate.
• Captures stay local. A packet capture is a file in your workspace. It only leaves your device if you save it as an artifact and share or upload it.

​

Session recording

Every SSH and Telnet session records automatically in asciicast v2 format with nanosecond timestamps. The recording captures input and output streams separately, preserving timing. You can replay a recording later with the original timing intact, or scrub through it to find a specific moment. Recording is on by default for solo sessions because operators routinely need to refer back. For shared and guest-link sessions, the same recording happens; participants should be told before sensitive work.

​

Voice, video, and shared sessions

Voice and video calls inside shared sessions use AWS Chime SDK in the same us-east-1 region as the rest of the cloud surface. Calls are not recorded by default. When recording is enabled per call, the recording is uploaded to the organization’s encrypted storage like any other artifact. Guest invite links carry a per-session token that grants the role you chose (viewer, co-worker) for the duration of the session. The link is invalidated when the session closes; there is no lingering grant to revoke.

​

Update and execution paths

The Electron renderer and the Go sidecar ship together as one signed installer. The sidecar is a binary inside the application bundle, not a separately downloaded payload. Updates replace both atomically through the signed update flow. The sidecar will not run if the parent process did not launch it. There is no service-mode install that runs the sidecar without the user signed in.

​

The boundary, restated

The sidecar:

• Holds plaintext keys and credentials at the moments they are needed.
• Talks to your network at the protocol layer.
• Indexes your local content for search.
• Will not accept connections from anything but the parent.
• Does not have its own AWS identity; AWS calls always go through the renderer.

The renderer:

• Drives the UI and the conversation.
• Holds short-term AWS credentials.
• Calls AppSync, KMS (for unwrap requests routed via the sidecar), and Bedrock.
• Renders approval prompts and logs operator decisions.
• Never holds a long-lived plaintext credential.

When the desktop process is signed in, both halves are inside your trust boundary. When you sign out, both halves zero their state — the identity-and-access page describes the sign-out path in detail.

​

Related