Pair-coding with someone in the same repo, every chat ping forces an alt-tab. Discord on one monitor. Slack on another. PR comments in a browser tab. Then you come back to the editor and the thing you were about to type is already half-gone from your head.
We got tired of it. We shipped GitChat, a VS Code extension that puts the chat panel where the code lives. No new account, no separate app. Here is how we built it, and a few things we had to throw away along the way.
The alt-tab tax
You are deep in a PR review. Something in the diff does not make sense. You want to ask the contributor a clarifying question. That is when the ritual kicks in. Cmd+Tab to Slack. Type the question. Wait. Read the reply. Cmd+Tab back. Whatever you were about to change is already half-remembered. Context is fraying before you type a single character.
Multiply that by a normal day of reviewing code with two or three other people, and every conversation taxes your focus twice: once on the way out, once on the way back. The fix we wanted was not a better chat app. It was a chat app that lives in the same window as the code.
Why we built it inside the editor and not as a web app
The obvious question is why bother with an extension at all. Why not a web app with a keyboard shortcut?
Three reasons pushed us toward the extension path.
First, friction. Installing an extension is one command: ext install GitchatSH.gitchat. No separate signup, no separate window.
Second, attention. Developers already have VS Code, Cursor, Windsurf, or Antigravity open for hours. A web app is a tab, and a tab gets closed. An extension lives where the work happens.
Third, identity. GitHub is already where developers have a profile, a follow graph, and a session token. An IDE extension can reuse that session the moment a user signs in. A web app has to rebuild it from scratch.
Quick note before we show code: the GitChat repo is not public yet; source-available is on the roadmap. The snippets below are real code from our repo, paraphrased for clarity.
The auth we settled on: VS Code session first, GitHub Device Flow as fallback
VS Code ships a built-in GitHub authentication provider, and most of the time it is the right choice for an extension. No redirect URI to configure, no client secret to protect, and the token is scoped the way the user expects.
Our primary path is a single call:
// src/auth/index.ts (simplified)
const GITHUB_SCOPES = [
"read:user",
"user:email",
"user:follow",
"repo",
];
const session = await vscode.authentication.getSession(
"github",
GITHUB_SCOPES,
{ createIfNone: true }
);
// session.accessToken is ready to use
For environments where the built-in provider is not available (some forks, some air-gapped setups), we fall back to the GitHub Device Flow. We POST to https://github.com/login/device/code, show the short user code in a VS Code notification, open the browser to the verification URL, and poll /login/oauth/access_token until the user approves.
Either way, the token lands in VS Code SecretStorage. Not globalState. Not a file on disk. If you are building a VS Code extension that handles any credential, this is the one API call that matters.
Your friends list is already on GitHub
We deliberately did not ask users to build a new social graph. GitHub already has one.
When you sign into GitChat, we query GET /user/following and GET /user/followers, intersect the two lists, and the set of mutual follows becomes your friends list. Zero manual adds. No invite links. If you already follow each other on GitHub, you can already message each other in the editor.
The same identity powers the rest of the product. Every user card we render can pull fresh GitHub stats on demand, because the session token already has the scope for it.
This also sets the table for what is coming next. When Team Channels ship, the same identity that powers your friends list drops you into a room with the maintainers and contributors of any repo you have committed to. No separate invite. Your commit history is the access token.
Realtime with Socket.IO and a 30-second heartbeat
For chat and presence we run a Socket.IO client inside the extension host. We chose socket.io-client over a raw WebSocket for two reasons: auto-reconnect with exponential backoff is built in, and named events map cleanly to our server-side rooms (per-DM, per-group, per-repo).
The presence protocol was where we spent the most tuning time. Too aggressive and the server melts under ping load. Too lazy and friends show "offline" mid-keystroke. We landed on a 30-second heartbeat against a 90-second backend TTL, which gives every client one full retry window before it gets marked offline.
// src/realtime/index.ts (simplified)
import { io } from "socket.io-client";
const PRESENCE_HEARTBEAT_INTERVAL_MS = 30_000;
this._socket = io(wsUrl, {
transports: ["websocket"],
reconnection: true,
reconnectionAttempts: Infinity,
reconnectionDelay: 1000,
reconnectionDelayMax: 30_000,
});
this._socket.on("connect", () => {
this._heartbeatTimer = setInterval(() => {
this._socket?.emit("presence:heartbeat");
}, PRESENCE_HEARTBEAT_INTERVAL_MS);
});
The other thing worth calling out is reconnectionAttempts: Infinity. A developer flight-mode-ing on a plane, or closing the laptop for lunch, is the common case. Giving up after N tries would just punish the user on return.
What is live, what is next
We ship fast. Here is where things stand right now and what is on deck.
| Status | Feature | What it does |
|---|---|---|
| Live | DM and Group Chat | Message anyone you follow on GitHub. Create groups with mutual friends. |
| Live | Friends and Presence | Your mutual follows become your friends list. See who is coding now. |
| Live | Developer Profiles | GitHub stats, top repos, and bio in a single card. |
| Soon | Community Channels | Star a repo and join its community room. |
| Soon | Team Channels | Contribute to a repo and get added to the team room. |
| Soon | Wave | Ping an online friend with one tap. |
GitChat vs Live Share vs Copilot Chat
People keep asking how this compares to Live Share and Copilot Chat, so here is the honest map. They solve different problems. Pick whichever one matches what you want to do.
| GitChat | VS Live Share | Copilot Chat | |
|---|---|---|---|
| What it solves | Human-to-human chat | Real-time collaborative editing | AI coding assistance |
| Identity | Your GitHub account | Live Share account | Copilot subscription |
| Scope | DMs, groups, repo channels | One shared editing session | Chat with AI about code |
| When to use it | Talk to the person you code with | Pair-program live on one file | Ask for code suggestions |
Live Share and Copilot Chat both solve real problems. We just needed a fourth thing that none of them do: text conversation with the actual human on the other end of a follow graph.
Try it in 30 seconds
One command, then sign in with GitHub.
ext install GitchatSH.gitchat
- Open VS Code, Cursor, Windsurf, or Antigravity.
- Press Cmd+P / Ctrl+P and paste the command above.
- Click the GitChat icon in the activity bar.
- Sign in with GitHub. Your mutual follows appear as your friends list.
A few honest notes before you install. The GitChat repo is not public yet; source-available is on the roadmap. Messages go through our backend over HTTPS; end-to-end encryption is not shipped yet, so do not put production secrets in a DM. The extension works best when the people you want to talk to install it too.
If it is useful, that is great. If something is broken, reply in the comments. We read everything.
Install from the VS Code Marketplace · Open VSX · gitchat.sh
Top comments (0)