RemoteDevTools

Problem

Developers increasingly work on machines they are not sitting in front of — remote workstations, cloud IDEs, always-on build boxes. The editor is there. The phone, the browser and a second laptop are not. Relaying editor state, terminal output, git status and commands across those surfaces is a protocol problem, not a CRUD form.

Context

RemoteDevTools is an agent, editor extension and web interface for monitoring and acting on a remote development environment. I designed the system and implemented the shared protocol, agent layer, extension surface and web client.

What I Owned

• the message protocol between editor, agent and clients
• the agent that relays IDE events and commands over WebSockets
• the editor extension that observes files, tasks, git state and terminal output
• the web surface for dashboards, file browsing and git inspection
• shared TypeScript types used by every package

Architecture

The first version is a relay, not a peer-to-peer mesh. The extension connects to an agent. Mobile and web clients connect to the same agent. Messages are JSON, with a small set of types: handshake, event, command and response.

Editor events include file changes, cursor movement, terminal chunks, git status, task lifecycle and build completion. Clients can later send commands back — open a file, run a command, inspect git — once execution is enabled.

Technical Decisions

I kept the shared package TypeScript-only, with no runtime dependencies, so every client can speak the same contract. The agent is a Bun WebSocket process. The web client is React and Vite. A React Native client sits on the same protocol. Terminal access is opt-in rather than on by default.

Hard Problems

The interesting work is state across unreliable connections: what the editor knows, what the agent has relayed, and what a client is allowed to do. Build notifications, file trees and git diffs all have to stay coherent without turning the agent into a second source of truth for the repository.

Trade-Offs

A relay is simpler to ship than peer-to-peer, and easier to reason about for auth and permissions. The cost is that the agent is on the path of every session. I deferred persistence and a full API server until the protocol and client surfaces were real, rather than building a SaaS control plane first.

Result / Current Status

The shared protocol, agent relay, extension event stream and web file / git viewers are implemented. Remote command execution and a production multi-tenant backend are still in progress. This is engineering work in active development, not a finished platform.

Stack

TypeScript · Bun · WebSocket · VS Code API · React · Vite · React Native

Links

• GitHub ↗