Light Remote did not begin as a product plan.
It began with a practical problem: I was used to having a remote path that let ChatGPT inspect a VPS, read files, run commands and help fix things. That path was becoming constrained, and I did not want to go back to copying commands from chat into a terminal and pasting output back.
The first idea was almost embarrassingly small: build a bridge that could relay a command to my VPS.
At first, executing one command was enough
The early bridge only needed a few primitives. Read a file, run a shell command, return the result. It immediately made remote work less manual.
Then the requirements grew. I needed file search, Git status and diffs, managed processes, long-running jobs, interactive terminals, Ctrl-C, resize, explicit device targeting and a way to explain policy denials.
At that point, “an API that runs shell commands” was no longer an honest description.
A shell is not a product boundary
Light Remote gradually split common work into meaningful capabilities: filesystem, search, Git, process, session, job and terminal. Generic exec still exists, but it is not supposed to be the universal hammer.
Specific tools make the workflow easier to understand and easier to govern. Reading a file should use a file operation. Interactive software should use a real PTY.
Local Wall is where a new device starts
A new device begins locally. Its Local Wall creates the one-time pairing code, the remote account creates the matching approval request, and the device owner approves locally. The MCP cannot mint its own A code or bypass that step.
Remote can ask to come in. The first door still opens from the device.
Main and Fleet appeared when one machine stopped being enough
Once ARM, AMD, Windows and other machines joined the picture, target identity became mandatory. Main carries Fleet authority, other devices keep their own Local Wall, and moving Main has to invalidate stale authority on the previous device.
A session never silently falls back to another machine. If the selected device is unavailable, the operation should fail there instead of succeeding somewhere surprising.
A terminal has to be a real terminal
For interactive work, a command box is not enough. Light Remote supports a real PTY or ConPTY lifecycle: start, input, output, resize, signal and stop. Ctrl-C is an actual terminal signal, not a decorative button.
That requirement pulled in durable sessions, asynchronous jobs, recent activity and recovery behavior. The bridge slowly became a remote computing system.
From a temporary bridge to a product
The original bridge proved the workflow was worth building. The product that followed moved trust into clearer boundaries: OAuth at the account edge, signed outbound channels at the device edge, explicit targets for sessions and device-local policy as the final deny point.
Light Remote still solves the same ordinary problem: I do not want to sit in front of every machine just to get useful work done. The difference is that the path is now explicit enough to trust.
No approved comments yet.