AI NewsOpen sourceAnnouncement
terminal-code puts a real VS Code window inside the terminal
An open-source project called terminal-code, from zenbu-labs, embeds a real VS Code window inside a terminal by combining code-server with a browser that renders through the kitty graphics protocol, and has gained 1,868 stars since it was created on 8 August.
Image: GitHub
Why it mattersA developer who works mostly in a terminal now has a way to open a full VS Code window in the same buffer without leaving the shell, and with an SSH mode that keeps the frontend local so remote editing does not lag on every keystroke.
The zenbu-labs terminal-code project embeds a real VS Code window inside a terminal window. It launched on 8 August and had gained 1,868 stars on GitHub when checked on 3 September.
What the tool actually does
Running tode in a terminal opens a VS Code pane in the same buffer. The project's own explanation of how it works is refreshingly short: it combines two existing pieces, terminal-browser (a browser that renders inside a terminal) and code-server (the Coder project that provides VS Code as a web application), so that a code-server session runs inside a terminal-rendered browser. Both projects are linked from the README as the credit for the underlying capability.
The interface is close to the VS Code CLI: tode <folder> opens the folder, tode <file> opens a file, -g file:line:col jumps to a position, -d a b runs a diff, --split right puts a new pane beside the current one, and --install-extension handles extensions. --import migrates settings, keybindings, snippets and extensions from an existing VS Code install, so an existing configuration moves across with the user.
The SSH mode is what makes it interesting
VS Code over SSH is usually painful. Running an editor on a remote host means every frame goes over the network before the screen updates, and every keystroke goes over before the editor reacts. The terminal-code project addresses this by splitting VS Code: tode --ssh user@host runs only the backend on the remote machine, and keeps the frontend on the local device. All the file operations and language services happen remotely, but the UI stays local, so it responds at the speed of the local machine.
This matches the split that VS Code's Remote-SSH extension uses, delivered without the VS Code desktop app around it. For a developer who is already in a terminal talking to a remote server, this makes remote editing feel local without changing tools.
What has to be true for it to run
The terminal has to support the kitty graphics protocol, which is how terminal-code draws the VS Code frames. That protocol is well supported on macOS and Linux through terminals such as kitty and Ghostty, and it is the reason this project could not have been released a few years ago. On Windows support is weaker: there is no official Windows build, and Windows terminals do not generally implement the protocol. The maintainers suggest running the Linux build inside WSL if a Windows user wants it today, and link one experimental port.
Two use cases are the clearest benefit. A terminal-first developer who wants an occasional full editor without switching windows gets one in the same window. And an engineer working on remote servers gets an editor that stays responsive because the frontend is local, which is the specific problem that makes many teams move to full IDEs.
The interest here is real: 1,868 stars in the four weeks since the repository was created is a real number, and it means the project has picked up an audience beyond the first week after launch. It is still early, at 15 megabytes of TypeScript on a first release, so a team relying on it in daily work should expect unfinished parts. The idea is clear enough to try.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
