blog: VS Code 1.137 Runs Agent Sessions in Their Own Process. Terminal Sharing Without SSH or VPN Does That for a Failing Build

src/data/blogPosts.json

@@ -1467,5 +1467,15 @@
   "tags": ["shell-online", "terminal-sharing", "end-to-end-encryption", "oauth", "team-collaboration"],
   "banner": "banners/team-terminal-sharing-sealed-so-the-service-cant-open-it.svg",
   "iso_date": "2026-09-09"
+ },
+ {
+  "slug": "vs-code-1-137-runs-agent-sessions-in-their-own-process-terminal-sharing-without",
+  "title": "VS Code 1.137 Runs Agent Sessions in Their Own Process. Terminal Sharing Without SSH or VPN Does That for a Failing Build",
+  "description": "How to pair-debug a failing build with terminal sharing without SSH or VPN, and how that compares to the Agent Host in VS Code 1.137.",
+  "date": "Sep 10",
+  "category": "Guide",
+  "tags": ["shell-online", "terminal-sharing", "vscode", "pair-debugging", "ci"],
+  "banner": "banners/vs-code-1-137-runs-agent-sessions-in-their-own-process-terminal-sharing-without.svg",
+  "iso_date": "2026-09-10"
  }
 ]

src/pages/blog/vs-code-1-137-runs-agent-sessions-in-their-own-process-terminal-sharing-without.astro

@@ -0,0 +1,58 @@
+---
+import BlogLayout from '../../layouts/BlogLayout.astro';
+
+const bodyContent = `<p>VS Code 1.137 shipped on September 9, 2026, and its <a href="https://code.visualstudio.com/updates/v1_137">release notes</a> describe the Agent Host in one sentence: "The agent host lets you connect to the same agent session from multiple VS Code windows." Agent harnesses run in a dedicated process, and every window is a client of that process rather than its owner. The idea underneath is old and good. The thing doing the work should not die when the window that started it closes, and every screen looking at it should be a viewer, not the owner. <span class="brand-shell">shell.online</span> applies that same split to any terminal process, and it is why terminal sharing without SSH or VPN works for a build that is failing on one machine while the person who can fix it sits at another.</p>
+
+<section>
+<h2>What the Agent Host actually changes</h2>
+<p>Under the hood VS Code now talks to the harness over the Agent Host Protocol (AHP), which the <a href="https://code.visualstudio.com/docs/agents/concepts/agent-host">concept documentation</a> describes as state-first: "The host is the source of truth," and each client subscribes to channels for sessions, chats, terminals, and changesets. Two properties fall out of that. Multiple clients can observe and control the same session and stay in sync, and a session can keep running when no editor or other client is connected at all.</p>
+<p>Reaching that host from another machine is the part worth reading closely. For remote sessions the Agent Host runs as a standalone process and exposes AHP as JSON-RPC over WebSocket. You start one with the code agent host command, it is protected with a connection token, and you reach it over SSH or a dev tunnel. The <a href="https://code.visualstudio.com/blogs/2026/08/26/agent-host-architecture">August architecture post</a> frames the payoff as running the host next to your workspace on another machine "while you connect from the desktop or web to check progress, review changes, and manage sessions."</p>
+<p>That is a good design for agent sessions. It also only covers agent sessions inside VS Code, and its remote path assumes the other person can be given SSH access or a tunnel. A failing build is often neither of those things. It is a plain process, and the colleague you want looking at it may have no account on the box and no reason to get one.</p>
+</section>
+
+<section>
+<h2>Terminal sharing without SSH or VPN, for one broken build</h2>
+<p>The <a href="https://shell.online">shell.online CLI</a> makes the same split, but smaller and more literal. It owns a pseudo-terminal and the process inside it on your machine. Browsers are viewers of that PTY and nothing more. One command wraps the build:</p>
+<pre><code>curl -fsSL https://shell.online/install | sh
+shell npm run build</code></pre>
+<p>The CLI prints a URL and an eight-character password only after the relay exists and the process has survived a short startup handshake. A build that dies in its first second reports the exit status and prints no link, so nobody is handed a dead URL. The session runs in the background by default and your own terminal comes back. Use shell --foreground when you want the output mirrored locally too, or shell attach with the session ID to take over from your own terminal later; Ctrl-X and then D detaches without stopping the build.</p>
+<p>Send the URL and the password to the colleague. They open it on a laptop or a phone, see the terminal the build is drawing, and can type into it if you left the link interactive. The relay is Cloudflare, but the CLI encrypts each frame with AES-256-GCM before it leaves the machine and the browser decrypts on arrival. The URL carries only a random salt fragment, and both ends derive the key from the password with 600,000 rounds of PBKDF2-HMAC-SHA256, as the <a href="https://shell.online/e2ee/">E2EE guide</a> spells out. Cloudflare still sees connection IPs, timing, and encrypted frame sizes, and the <a href="https://shell.online/security/">security page</a> lists that metadata rather than glossing over it. Terminal contents are not persisted server-side.</p>
+<p>The access model is blunt and worth saying out loud: the URL and the password together are a bearer credential. Anyone holding both can view the terminal and, unless the link is read-only, type into it with the permissions of the wrapped process. That is the whole trust model. It is why an interactive build link goes to one named person, not to a channel.</p>
+</section>
+
+<section>
+<h2>Read-only when the other person should only look</h2>
+<p>Often the second person does not need the keyboard. They need to see the last two hundred lines of a linker error, or watch the test runner reach the case that hangs. For that:</p>
+<pre><code>shell --read-only npm run build</code></pre>
+<p>Read-only is enforced at the relay Worker, not by the page in the browser. Ordinary browser input and a confirmed EOF are rejected server-side, so opening DevTools or hand-crafting WebSocket frames does not turn the link into an interactive one. Access mode is fixed when the share is created and cannot be weakened afterwards. If you later decide the viewer should type, you start a new share.</p>
+<p>Read-only also narrows what the bearer credential grants. With both values a viewer can see everything the build prints, and nothing else.</p>
+</section>
+
+<section>
+<h2>What happens when the network drops mid-build</h2>
+<p>This is where "the host is the source of truth" earns its keep. The <a href="https://shell.online/reliability/">reliability page</a> states the rule directly: relay and browser failures are treated as recoverable display failures, never as permission to terminate local work. The CLI and the browser both reconnect with bounded backoff, and an ordinary share link stays recoverable for 12 hours after its host disconnects. The build keeps running through all of it, because it never depended on the viewer.</p>
+<p>Build output is bursty, which creates a second problem: a viewer can fall behind. The CLI keeps a bounded local ring buffer so a viewer who arrives late or reconnects gets the screen restored, and if live output outruns the network or the browser's rendering, stale display work is dropped and one authoritative screen snapshot is sent instead. PTY reads never block waiting on Cloudflare. Queues are bounded and writes time out, so a process that writes faster than the relay can carry keeps running at full speed locally. The 0.11.0 entry in the changelog of the <a href="https://github.com/TeoSlayer/shell.online">shell.online repository</a> records a fix in exactly this area: authenticated E2EE recovery snapshots are now preserved during relay backpressure, so large output can no longer eject viewers to the password screen. Builds are the workload that finds that kind of bug.</p>
+<p>Two more lifecycle details matter for a pairing session. When the build exits, the share closes on its own; the link does not outlive the process. If you want a harder deadline, shell --auto-close 2h npm run build closes the share after two hours even if the process is somehow still going. And if the colleague opens the link from a phone, the session grid switches from 120 by 36 to 80 by 24 for everyone until the last phone leaves, because viewers never own PTY sizing. Every viewer sees the same line wrapping in the compiler output.</p>
+</section>
+
+<section>
+<h2>Where the two designs differ, honestly</h2>
+<p>The Agent Host carries structured state: chats, changesets, tool approvals, terminals as addressable resources. <span class="brand-shell">shell.online</span> carries one PTY and nothing else. It does not know what a build is, cannot show a diff, and has no notion of approving a tool call. What it gives up in structure it gets back in reach. Any process on any machine that can run the static binary qualifies, including the OpenWrt routers and Raspberry Pi boards in the <a href="https://shell.online/platforms/">platform matrix</a>, and any viewer with a modern browser, with no account, SSH key, tunnel, or VPN on either side.</p>
+<p>The remote path is the sharpest contrast. A remote Agent Host is reached over SSH or a dev tunnel with a connection token. A <span class="brand-shell">shell.online</span> link is reached over HTTPS with a URL and a password, and the relay only ever handles ciphertext. Both are bearer credentials in practice. The difference is what the holder can reach: an SSH session is the whole machine, while a share link is one process, at that process's permissions, and optionally with no keyboard at all.</p>
+<div class="callout"><p>Rule of thumb for a failing build: an interactive link to the one person who will type the fix, a read-only link to everyone who just wants to watch it go green, and let the share close itself when the build exits.</p></div>
+<p>The full flag list, including the auto-close grammar and exit codes, is in the <a href="https://shell.online/cli/">CLI reference</a>. The broader case for a live terminal link is in <a href="https://pilotprotocol.network/blog/shell-online-live-terminal-browser-link">the post that introduced shell.online on this blog</a>.</p>
+</section>
+
+<div class="cta"><h3>Share the build, not the box</h3><p>One command, one link, one password. The process stays on your machine and the relay never sees plaintext.</p><a href="https://shell.online/">Try shell.online</a></div>`;
+---
+<BlogLayout
+  title="VS Code 1.137 Runs Agent Sessions in Their Own Process. Terminal Sharing Without SSH or VPN Does That for a Failing Build"
+  description="How to pair-debug a failing build with terminal sharing without SSH or VPN, and how that compares to the Agent Host in VS Code 1.137."
+  date="September 10, 2026"
+  tags={["shell-online", "terminal-sharing", "vscode", "pair-debugging", "ci"]}
+  canonicalPath="/blog/vs-code-1-137-runs-agent-sessions-in-their-own-process-terminal-sharing-without"
+  author={{ name: 'Artemii Amelin', type: 'Person' }}
+  bannerImage="/blog/banners/vs-code-1-137-runs-agent-sessions-in-their-own-process-terminal-sharing-without.svg"
+>
+  <Fragment set:html={bodyContent} />
+</BlogLayout>