DEV Community: psychomafia.tiger

A clone of our VS Code extension appeared on OpenVSX five days before we open-sourced the repo. It has 5,090 downloads and is using our GitHub OAuth app.

psychomafia.tiger — Thu, 23 Apr 2026 03:08:39 +0000

Names (fyltroven, Mapkoforceps) are used because they are public on OpenVSX and GitHub. We are not claiming intent. Our OpenVSX takedown report is open as of writing.

We did not expect to find this

We flipped the repo public yesterday. April 21, 10:29 UTC. A private repo the day before, an MIT license the day after, that kind of week.

This morning we checked our OpenVSX listing and our extension was there twice.

Ours: gitchat.gitchat, 11,308 downloads, verified: true. Published yesterday.

The other one: fyltroven.gitchat-fast-tool. 5,090 downloads. unrelatedPublisher: true. Published April 16.

Five days before we open-sourced. Our repository was still private on April 16. Nobody outside the team had the source. The clone was already live.

We pulled its package.json expecting a half-thorough rebrand. name, publisher, homepage, bugs, repository were all updated. One field was not. And the further we dug into the shipped bytes, the less the interesting question was how someone rebranded our code, and the more it became how they had our code at all.

The fake listing on OpenVSX. Orange banner at top is OpenVSX's own unrelatedPublisher: true flag.

Side by side

	Ours	The clone
Namespace	`gitchat.gitchat`	`fyltroven.gitchat-fast-tool`
Publisher verified	true	false
OpenVSX flag	normal	`unrelatedPublisher: true`
OpenVSX downloads	11,308	5,090
Version	1.1.5	1.0.5
License	MIT	MIT
Published	2026-04-21 10:29 UTC	2026-04-16 15:29 UTC

Both listings are public. Open either URL and you see what we saw.

The field they forgot

The clone's package.json from the OpenVSX CDN:

GET https://open-vsx.org/api/fyltroven/gitchat-fast-tool/1.0.5/file/package.json

{
  "name": "gitchat-fast-tool",
  "publisher": "fyltroven",
  "repository": {
    "url": "https://github.com/Mapkoforceps/gitchat-fast-tool.git"
  },
  "homepage": "https://github.com/Mapkoforceps/gitchat-fast-tool#readme",
  "bugs": {
    "url": "https://github.com/Mapkoforceps/gitchat-fast-tool/issues"
  },
  "qna": "https://github.com/GitchatSH/gitchat_extension/issues"
}

Every other metadata field got rebranded. qna was left pointing at our repo.

The qna URL points to our repository, the one we made public yesterday. Everything else is rebranded. This one they missed.

At that point it was a copy, not a coincidence. The question was how deep.

Seven minutes

GitHub's REST API for the clone's repo:

repo: Mapkoforceps/gitchat-fast-tool
  created_at: 2026-04-16T15:22:16Z
  pushed_at:  2026-04-16T15:24:58Z

OpenVSX for the listing:

timestamp: 2026-04-16T15:29:02Z

Repo created 15:22. First push 15:24. Published to OpenVSX 15:29. Seven minutes total. Nobody writes a Socket.IO chat extension with a sidebar webview in seven minutes. The only thing you can do in that window is upload code you already had.

Commit history on the clone's repo. Initial commit at 15:22, push at 15:24, OpenVSX publish at 15:29.

And our source was still private on April 16. It stayed private for five more days.

The part we cannot explain

The repository was on GitHub with visibility private until April 21 at 10:29 UTC. The clone was already on OpenVSX on April 16 at 15:29 UTC. Between those two timestamps, someone had our code on their laptop, packaged, and live.

We do not know how.

What we have checked so far:

GitHub access logs for the repo show only authorized team members.
There is no mirror of the source, no CI artifact we accidentally made public, no leaked log that we have found.
The project was not invisible before we shipped. We posted in r/vscode this week describing what we were building. Anyone reading that thread would have known the project existed and roughly what it did. The thread did not include a source archive or a binary.

That r/vscode thread predates the clone. If you find it and check the timestamps you can draw your own line between points. We are not going to draw it for you, because we do not know the real answer and guessing in print would be unfair to whoever did or did not do this.

What we can say is narrow. Our repo was private when the clone appeared. The clone's publisher had a packaged copy of our extension five days before the code was public. If anyone reading this has seen a pattern like it, on OpenVSX or anywhere else, we would like to hear about it.

Inside the `.vsix`

OpenVSX lets anyone download the packaged extension. We pulled the clone's .vsix (8.75 MB) and unzipped it.

Brand assets:

gitchat_banner.png
gitchat_hook_cover.gif
gitchat_myrepo.png
gitchat_social_cover.png
gitchat_top people.png
gitchat_toprepo.png
feature-chat.png
feature-explore.png
feature-friends.png
feature-profile.png

Unzipped .vsix folder. Filenames carry our brand prefix unchanged.

These are our image files, filename prefix and all. The clone did not rename them.

The minified JS bundle (dist/extension.js, 484 KB) was not rebuilt. strings on it:

{id:"gitchat.signIn",handler:...}
{id:"gitchat.messageUser",handler:...}
{id:"gitchat.viewMyProfile",handler:...}
"Sign in to view your GitChat profile."
"Enter GitHub username to message"

The package.json registers 15 command IDs under gitchat.* (gitchat.signIn, gitchat.signOut, gitchat.userMenu, etc). There is no reason for an extension called gitchat-fast-tool under publisher fyltroven to be registering commands in our namespace, other than that is what was on disk when they ran vsce package.

The .vsix also shipped a .claude/settings.json with a PreToolUse hook for docs/contributors/${USERNAME}.md. That is our internal contributor-doc workflow. You do not ship somebody else's Claude Code config file by accident.

It gets worse: the clone uses our backend

At this point we thought we were looking at an IP issue. Then we opened the contributes.configuration.properties block of the shipped package.json:

{
  "gitchat.apiUrl": {
    "default": "https://api-dev.gitchat.sh/api/v1"
  },
  "gitchat.wsUrl": {
    "default": "https://ws-dev.gitchat.sh"
  },
  "gitchat.githubClientId": {
    "default": "Ov23liXf7KFWwKzcOHE0",
    "description": "GitHub OAuth App Client ID for device flow authentication"
  }
}

Those are our servers. That client ID is the OAuth app we built and registered under our team's GitHub account.

What happens when a user signs into the clone. Every arrow ends on our infrastructure.

Reading the rest of the bundle, what happens to a user who installs the clone:

They install fyltroven.gitchat-fast-tool from OpenVSX.
They hit Sign In. The extension starts a GitHub device flow using our client ID.
GitHub shows them a device-code screen for the OAuth app registered under our team. They grant permissions to that app.
Their VS Code gets a token issued against our OAuth app.
The extension calls api-dev.gitchat.sh and opens a socket to ws-dev.gitchat.sh. Our backend validates the token and creates or looks up the user record in our database.
"GitChat Fast Tool" shows up in their sidebar. Every message they send lives on our servers under a token issued by our app.

We did not sign off on any of this. We found out because we downloaded the .vsix.

One honest caveat. GitHub's OAuth device flow does have a known public-client-ID-impersonation issue (Praetorian writes about it). In our specific case the device flow is doing what it is specified to do, tokens are scoped by what the user clicks through, and the backend is ours so nothing exfiltrates past us. The awkward fact is that 5,090 people installed an extension from an unverified publisher, and that extension has been quietly running through our OAuth app and our database the whole time. Neither we nor they knew.

Where did 5,090 installs come from

Google   "gitchat-fast-tool"       : no matches outside the listing
Reddit   search                    : no results
Twitter  search                    : no results
GitHub   repo stars                : 0
Blog posts, social media promotion : none found

5,090 installs with zero discoverable source. We do not have an answer. We are not calling anyone an install farm. We just cannot make 5,090 and zero line up.

If you have seen this on OpenVSX before, or you know of anyone running detection on install-count anomalies for VS Code marketplaces, talk to us.

The publisher

login:       Mapkoforceps
name:        null
bio:         null
email:       null
blog:        (empty)
location:    null
company:     null
followers:   0
created:     2026-03-13T11:46:50Z
public_repos: 2

The GitHub profile that published the clone. Created 34 days before the publish, no profile info, no followers.

Two repos on that account. oogymera, created the same day the account was, empty, zero stars. gitchat-fast-tool, the clone.

This is a thin profile by any standard. We are not attributing intent. We noticed the same signals that you probably noticed reading that block, and they are the reason we decided a cease-and-desist email would not go anywhere useful.

What we did

Filed an OpenVSX takedown on the open-vsx.org issue tracker, citing the unrelatedPublisher flag, the qna URL mismatch, the identical minified bundle, and the backend config.
Flipped our repo public on MIT at github.com/GitchatSH/gitchat_extension (the evidence chain is in the commit history, so we wanted that public regardless).
Started planning the OAuth client ID rotation and the user-migration that goes with it.

No email to the clone publisher. The profile above is why.

What we are asking

Three questions, picked because they are things we genuinely do not know the answer to.

One. Our repo was private on April 16. How does a clone of a private repo show up on OpenVSX? If you have seen a clone appear before the source went public, we would like to hear it.

Two. 5,090 downloads and zero footprint. If this shape is familiar to anyone, tell us what you think happened and how you would check.

Three. If you ship an open-source VS Code extension with a backend, your config defaults become part of a public surface you cannot take back. We knew that about our own release. We did not expect the defaults to be absorbed by a rebranded listing with five thousand downloads, five days before we shipped the source. If you have seen config-inheritance like this in a cloned extension, share the details.

We are the GitChat team. Our real extension is gitchat.gitchat on OpenVSX and GitchatSH.gitchat on the VS Code Marketplace. Source at github.com/GitchatSH/gitchat_extension on MIT. Comments are on.

How We Built a Chat Layer for GitHub Right Inside VS Code

psychomafia.tiger — Fri, 17 Apr 2026 08:23:16 +0000

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

How to run Claude Code, Gemini, and Codex side-by-side from Discord

psychomafia.tiger — Wed, 08 Apr 2026 06:27:02 +0000

Last week I had Claude Code running a refactor in one terminal tab, Codex generating boilerplate in another, and Gemini reviewing a PR in a third. I alt-tabbed to check on Claude Code and it had been waiting for a permission prompt for 20 minutes. Codex had finished and I didn't notice. Gemini was halfway through but I couldn't tell from the tab title.

Three agents, three terminal windows, zero visibility when I'm not staring at them.

Claude Code is great for complex multi-file work but burns tokens on simple tasks. Codex is faster and cheaper for straightforward changes. Gemini handles code reviews well. I wanted to use all three, but managing them in separate terminals wasn't working. Especially when I step away from my desk.

I set up OpenACP to run all three from Discord. My team already uses it, and threads keep each agent session separate.

What this setup looks like

OpenACP is a self-hosted bridge that connects AI coding agents to messaging platforms. For Discord specifically, it creates a forum channel where each agent session gets its own thread. You can run Claude Code in one thread, Codex in another, and Gemini in a third, all at the same time.

Discord Server
└── #openacp-sessions (forum channel)
    ├── Fix auth middleware race condition   (Claude Code)
    ├── Add user endpoint scaffolding        (Codex)
    └── Review PR #42 error handling         (Gemini)
└── #openacp-notifications
    └── Completion alerts with links back to threads

Each thread shows real-time streaming: file reads, code writes, terminal commands, all as they happen. When an agent needs to write a file or run a command, Allow and Reject buttons show up in the thread. I approve from my phone and the agent continues.

Setting up Discord

The Discord setup takes about 10 minutes. You need a server where you have Manage Server permission.

1. Create a bot on the Discord Developer Portal

Go to discord.com/developers/applications, create a new application, then go to Bot in the sidebar. Reset the token and copy it immediately. Under Privileged Gateway Intents, enable Message Content Intent.

2. Generate an invite URL

Go to OAuth2 → URL Generator. Check bot and applications.commands under Scopes. Under Bot Permissions, check: Manage Channels, Send Messages, Send Messages in Threads, Create Public Threads, Manage Threads, Manage Messages, Embed Links, Attach Files, Read Message History, Use Slash Commands, Add Reactions.

Or just use this permission integer in the URL:

https://discord.com/oauth2/authorize?client_id=YOUR_APP_ID&scope=bot+applications.commands&permissions=328565073936

Replace YOUR_APP_ID with your Application ID from the portal.

3. Invite the bot and grab the Guild ID

Open the invite URL, select your server, authorize. Then enable Developer Mode in Discord settings (User Settings → Advanced), right-click your server name, copy the Server ID.

4. Install and configure OpenACP

npm install -g @openacp/cli
openacp

The setup wizard asks which platform you want. Pick Discord, paste the bot token, paste the Guild ID. It validates both and saves the config.

Start it:

openacp start

OpenACP creates two channels automatically: #openacp-sessions (a forum channel for sessions) and #openacp-notifications (a text channel for completion alerts). The bot registers slash commands within seconds.

Installing multiple agents

By default OpenACP uses Claude Code. To add more agents:

openacp agents install gemini
openacp agents install codex

These pull from the ACP registry. You can see everything available with openacp agents.

Running agents side-by-side

Once you have multiple agents installed, open your Discord server and type:

/new claude ~/projects/backend

A new forum thread opens. It starts as "🔄 claude — New Session" while it initializes. Once you send your first message and the agent responds, it auto-renames to a short summary of the task, something like "Fix auth middleware race condition".

While that's running, open a new thread:

/new codex ~/projects/backend

Now Codex is working on the same project in a separate thread. You can give it a different task. Both agents run in parallel, each in their own isolated session.

Need a code review? Third thread:

/new gemini ~/projects/backend

Three threads, three agents, one Discord server. Each one streams independently. When a session finishes, a completion notification goes to #openacp-notifications with a link back to the thread.

How the thread UI works

Each thread shows:

Tool call embeds with a colored sidebar. Blue while the agent is working, green when done, red on error. These group all the file reads, writes, grep calls, and terminal commands into a single embed so the thread doesn't flood with individual messages.
Action row buttons below the embed: Low, Medium, High to control how much detail you see, and Cancel to abort. No slash commands needed for the common actions.
Permission buttons when the agent wants to do something destructive. Allow or Reject, right there in the thread. If you're on your phone and the agent wants to run rm -rf node_modules && npm install, you see the full command and can decide.
Auto-naming after the first prompt. The thread renames from "🔄 claude — New Session" to a short summary of the task, like "Fix auth middleware race condition".

Continuing or changing agents

/newchat starts a fresh session in the same thread with the same agent and workspace. Useful when you want a clean slate without losing the conversation history above.

To use a different agent, run /new codex ~/projects/backend from any channel. It opens a fresh thread. There's no way to swap agents inside an existing thread, which honestly keeps things cleaner. Each thread is one agent, one task.

A workflow I use daily

Morning. I have a PR to review and two bugs to fix.

Thread 1: /new gemini ~/projects/api. I send "Review the diff on branch feature/notifications, focus on error handling." Gemini reads the diff, posts comments in the thread. I read them on my phone over coffee.

Thread 2: /new claude ~/projects/api. I send "The webhook handler in src/webhooks/stripe.ts is silently swallowing errors. Fix it and add proper logging." Claude Code digs through the codebase, finds the issue, proposes a fix. I tap Allow when it wants to write the file.

Thread 3: /new codex ~/projects/api. I send "Add a GET endpoint at /api/v1/health that returns the server uptime and version." Simple task, Codex handles it in under a minute.

All three finish at different times. Each one posts a completion notification to #openacp-notifications. I check the results when I'm back at my desk, or from my phone if I'm still out.

Total cost for the morning: usually under $5. OpenACP tracks per-session token usage and cost, and you can set monthly budget limits that pause the agent when hit.

Slash commands reference

These register automatically when OpenACP starts:

Command	What it does
`/new [agent] [workspace]`	Create a new session in a new thread
`/newchat`	New session with same agent and workspace
`/cancel`	Cancel the session in the current thread
`/status`	Show session or system status
`/sessions`	List all active sessions
`/menu`	Open the control panel
`/agents`	Browse available agents
`/install [name]`	Install an agent
`/handoff`	Get a terminal command to continue locally
`/dangerous`	Toggle auto-approve for all permission requests
`/outputmode [low	medium
{% raw %}`/tts [on	off]`
`/doctor`	Run system diagnostics
`/help`	Show all commands

Things to know

Everything except the model API calls stays on your machine. No relay, no third-party storing your sessions. Swapping between agents doesn't change your messaging setup.

Some things I ran into. The forum channel works best with Discord Community mode enabled. Without it, OpenACP falls back to a regular text channel with threads, which is less organized. Discord's rate limits on message edits mean streaming output sometimes lags a couple seconds behind the actual agent. And if you're running three agents simultaneously, you're paying three sets of API costs, so the budget limit feature is worth setting up early.

Getting started

npm install -g @openacp/cli
openacp

Pick Discord during setup. The wizard validates your bot token, connects to your server, and creates the channels. Takes about 10 minutes total.

Source: https://github.com/Open-ACP/OpenACP
Discord setup guide: https://openacp.gitbook.io/docs/platform-setup/discord
ACP registry (browse agents): https://agentclientprotocol.com/get-started/registry

MIT licensed. I'm a contributor to OpenACP. Happy to answer questions about the multi-agent setup or Discord integration below.

How OpenACP talks to 28+ AI agents through one protocol — architecture of a self-hosted messaging bridge

psychomafia.tiger — Mon, 06 Apr 2026 09:16:46 +0000

I needed Claude Code to talk to Telegram. Not a chatbot — the actual coding agent, running on my machine, reading my files, writing code. I wanted to send it a task from my phone and get structured updates back, including permission prompts I could approve with a tap.

Parsing terminal stdout wasn't going to cut it. I tried that approach early on and it kept breaking whenever the agent's output format changed.

That's when I found OpenACP and started contributing. What made it work where my hacky approach didn't was a protocol layer underneath: the Agent Client Protocol (ACP), an open standard that lets any client communicate with any compatible coding agent through structured JSON-RPC messages.

Here's how the architecture works.

The problem: agents live in your terminal

AI coding agents — Claude Code, Gemini CLI, Codex, and others — are powerful but they assume you're sitting at a terminal. Leave your desk and the agent hits a permission prompt? It waits. You come back 40 minutes later to find it's been idle the whole time.

The workarounds people try: SSH into a tmux session on mobile (fragile), VPN + remote desktop (slow), or just hope nothing needs approval. None of these are actually good.

What you want is a structured bridge: your messaging app on one side, the coding agent on the other, with a session manager in between that handles streaming, permissions, and multiple agents at once.

OpenACP's three layers

OpenACP is a self-hosted bridge between messaging platforms (Telegram, Discord, Slack) and AI coding agents. Everything runs on your machine. The architecture has three layers:

┌────────────────────────────────────────────────────┐
│                    Your Phone                       │
│            Telegram / Discord / Slack               │
└──────────────────────┬─────────────────────────────┘
                       │
          Platform API (grammY / discord.js)
                       │
┌──────────────────────▼─────────────────────────────┐
│              Layer 1: Adapter                       │
│  Translates platform messages to internal events    │
│  Handles: buttons, topics/threads, streaming,       │
│  rate limiting, message chunking                    │
└──────────────────────┬─────────────────────────────┘
                       │
┌──────────────────────▼─────────────────────────────┐
│           Layer 2: Session Bridge                   │
│  Routes messages between adapters and agents        │
│  Manages: session lifecycle, prompt queue,          │
│  permission gates, cost tracking, parallel sessions │
└──────────────────────┬─────────────────────────────┘
                       │
            ACP protocol (JSON-RPC over stdio)
                       │
┌──────────────────────▼─────────────────────────────┐
│         Layer 3: Agent Connection                   │
│  Spawns agents as subprocesses, speaks ACP          │
│  Handles: initialize, session/new, session/prompt,  │
│  event streaming, permission relay                  │
└────────────────────────────────────────────────────┘
                       │
              Claude Code / Gemini CLI / Codex / ...
                       │
                  Your Codebase

Each layer only talks to its neighbors. The adapter doesn't know which agent is running. The agent doesn't know whether it's talking to Telegram or Discord. The session bridge is the glue.

Layer 3: how agents actually communicate

This is the part that was hardest to get right without a protocol.

OpenACP spawns each agent as a subprocess and communicates over stdin/stdout using the Agent Client Protocol. ACP is built on JSON-RPC 2.0 — structured messages, not raw text.

The lifecycle has three phases:

1. Initialize — OpenACP tells the agent what capabilities the client supports (file operations, terminal access) and the agent responds with what it can do:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": 1,
    "clientCapabilities": {
      "fs": { "readTextFile": true, "writeTextFile": true },
      "terminal": true
    }
  }
}

2. Create session — Point the agent at a working directory:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "session/new",
  "params": { "cwd": "/home/user/my-project" }
}

3. Prompt — Send a task. The agent streams back typed events as it works:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "session/prompt",
  "params": {
    "sessionId": "abc-123",
    "prompt": [{ "type": "text", "text": "Fix the auth bug in middleware.ts" }]
  }
}

While working, the agent sends back events:

agent_message_chunk — the agent's reasoning, streamed as it thinks
tool_call / tool_call_update — file reads, writes, grep, terminal commands
usage_update — token counts and cost
plan — the agent's internal task plan

And the critical one: request_permission. When the agent wants to do something that requires approval — write a file, run a destructive command — it sends a structured permission request. OpenACP turns that into a Telegram button or Discord interaction. The agent blocks until you respond.

This is why the protocol matters. Without it, you're parsing terminal output trying to figure out if the agent is asking a question or just printing something. With ACP, a permission request is an explicit method call with structured options. There's no ambiguity.

Why one protocol means 28+ agents

Here's the real payoff.

Because OpenACP speaks ACP, it works with every agent that also speaks ACP. The ACP registry lists 28+ agents right now — Claude Code, Gemini CLI, Codex CLI, GitHub Copilot, Cursor, Cline, goose, Junie, Qwen Code, and more.

Adding a new agent to OpenACP means registering it, not building a custom integration. When you run:

openacp agents install gemini

OpenACP pulls the agent definition from the registry, resolves its distribution (npm, pip, or binary), and installs it. From that point on, you can spin up a Gemini session alongside your Claude Code session, each in its own Telegram topic or Discord thread.

The typical setup: Claude Code running a longer task in one Telegram topic while you ask Gemini something quick in another. Same bridge, same interface, different agents.

Quick note: ACP is not MCP

This confused me at first. Model Context Protocol (MCP) connects an AI model to tools — databases, APIs, browser automation. Agent Client Protocol (ACP) connects a user interface to a coding agent — prompts, streaming, permissions, sessions.

They're complementary layers. Claude Code uses MCP internally to talk to tool servers, and speaks ACP externally to talk to whatever client is driving it — VS Code, a terminal, or OpenACP.

What a session looks like end-to-end

When I send "Fix the auth bug in middleware.ts" to my Telegram bot:

Telegram adapter receives the message, identifies the session
Session bridge queues the prompt, routes it to the right agent instance
Agent connection sends session/prompt to Claude Code via ACP
Claude Code reads files → comes back as tool_call events → streamed to Telegram
Claude Code greps the codebase → tool_call event → streamed
Claude Code wants to write a fix → request_permission → Approve/Deny button in Telegram
I tap Approve from my phone
Session bridge relays the approval → Claude Code writes the file → end_turn

Total messages exchanged over ACP: dozens. Time I spent: one tap.

What stays local

Everything except the model API call. Your code, sessions, config, and cost data stay on your machine. The agent calls Anthropic/Google/OpenAI for inference — that's the tradeoff — but the orchestration layer is fully yours. No relay, no third-party storing your session history.

And because the bridge is protocol-based, swapping agents doesn't change anything else. Different subprocess, same messaging setup.

Try it

npm install -g @openacp/cli
openacp

Setup wizard handles the rest. Platform guides in the docs.

Self-hosting AI coding agents: why it matters and how to do it

psychomafia.tiger — Thu, 02 Apr 2026 03:28:04 +0000

A few months ago I audited where my code was going.

Not the deployed code. The code I was writing. Every snippet I pasted into a chat window, every file I attached to get a review, every prompt I sent while debugging at 2am - all of it passed through servers I had no visibility into. I wasn't paranoid about it. I just wanted to know.

The answer was: a lot of places.

That started me down the path of figuring out how to keep AI in my workflow without giving up control of what I was working on.

What "self-hosted AI" actually means in 2026

When people say self-hosted AI, they usually mean running a local model. Ollama, LM Studio, a quantized Llama on a machine with a decent GPU. That's one approach.

But for coding work, local models still can't match Claude Code or Gemini CLI. Not in context windows, not in tool use, not in how well they understand large codebases.

So I stopped thinking about self-hosting the model and started thinking about self-hosting everything around it.

The agent runs on my machine. It reads my files locally. The API call goes to Anthropic or Google, I accept that tradeoff. But the session state, the conversation history, the permissions, the tooling layer? None of that needs to leave my control.

The pieces you actually want to own

When you run claude or gemini in a terminal, the agent itself is already local. What's not local:

Where you interact with it (usually a terminal you have to be physically at)
How sessions are managed (you open and close them manually)
How you approve or deny actions when you're not at your desk
Whether you can run multiple agents in parallel
Cost visibility (what did this session actually cost me?)

These are orchestration problems, not model problems. And orchestration is exactly what can and should be self-hosted.

OpenACP

I started contributing to OpenACP because it solves this specific layer.

It's a self-hosted bridge that connects AI coding agents to Telegram, Discord, or Slack. You install it on your machine, point it at your workspace, and from that point on you interact with your agents through whatever messaging app you already use.

The setup is straightforward:

npm install -g @openacp/cli
openacp

First run opens a setup wizard. You pick your platform, paste your bot token, choose a workspace, and pick a default agent. Takes about 5 minutes.

After that, your Telegram (or Discord, or Slack) becomes the interface for your agents.

Why messaging apps instead of a web UI

I originally expected to build some kind of dashboard. But then I thought about when I actually need to interact with my agents: on my phone, on the bus, between meetings.

I'm already in Telegram. My team is already in Discord. Building yet another web app to check on didn't make sense when the notification layer was already there.

The practical upside is permission handling. If an agent wants to run rm -rf or write to a sensitive file, it asks first. That prompt shows up as inline buttons in the chat, and I tap approve or deny from wherever I am. No need to rush back to a terminal.

One install, multiple agents

OpenACP uses the ACP registry to discover agents. Claude Code, Gemini CLI, Codex, Cursor, Cline, goose, and a bunch of others are all supported.

openacp agents                     # see what's available
openacp agents install gemini      # install from registry

You can run different agents in different sessions at the same time. I usually have Claude Code running a longer task in one thread while I'm asking Gemini something quick in another. Each session gets its own topic/thread in the chat.

The daemon side

Running this as a background service is what makes it actually useful day-to-day.

openacp start   # start daemon
openacp stop    # stop it
openacp status  # check
openacp logs    # tail logs

The daemon survives terminal sessions and starts on boot. Close your laptop, open it at a coffee shop, your agents are still there. Sessions persist too, so you reconnect and pick up where you left off.

If something breaks, run openacp doctor. It checks your config, bot token, agent installs, and daemon status, then tells you exactly what's wrong.

What stays private

I want to be clear about what this doesn't do. The API calls to Anthropic or Google still happen. The model inference is not local.

But here's what stays on your machine:

Your code and files (the agent reads them locally)
Your session history and conversation state
Your config and credentials
Your cost data and usage logs

The orchestration layer is fully yours. There's no relay service sitting between you and your agent, and no vendor storing your session history on their end.

The other side of this: if I decide to switch from Claude Code to Gemini for a project, I change one config value. The messaging setup, the sessions, the permissions, the cost tracking, all of that stays the same. I'm not locked into one agent vendor.

A typical day with this setup

Morning. I open Telegram, send "review the PR on branch feature/auth" to my bot. Claude Code starts reading the diff, leaves comments in the chat. I read them on the train.

Afternoon. I need to scaffold a new API endpoint. I open a second session, this time with Gemini. It generates the boilerplate, I review the output in Discord while in a meeting (don't tell my manager).

Something fails in CI. I forward the error log to the bot, ask it to investigate. It greps through the codebase, finds the issue, proposes a fix. I approve the file write from my phone.

End of day. openacp api status shows me 3 sessions ran, roughly $4.20 in API costs. Everything's logged locally.

Getting started

npm install -g @openacp/cli
openacp

The wizard asks 5 things: platform, bot token, workspace path, default agent, run mode. If you already have a Telegram bot from @botfather, the whole thing takes under 5 minutes.

For running it long-term, switch to daemon mode:

openacp start

After that it's just there. You message your bot and things happen.

Detailed platform guides (Telegram, Discord, Slack) are in the docs.

Links

Source: https://github.com/Open-ACP/OpenACP
Docs: https://openacp.gitbook.io/docs
ACP registry: https://agentclientprotocol.com/get-started/registry

MIT licensed. I'm a contributor, happy to answer questions.

How to control Claude Code from Telegram, Discord, or Slack (self-hosted, open source)

psychomafia.tiger — Wed, 01 Apr 2026 11:22:01 +0000

My workflow broke the moment I stepped away from my desk.

I had Claude Code running a large refactor. Left to grab lunch. By the time I came back, it had hit a permission prompt and been sitting idle for 15 minutes, waiting for me to press "yes" on a machine I wasn't at.

That's why I started contributing to OpenACP.

The problem

Claude Code, Gemini CLI, Codex - these tools are powerful but they assume you're sitting at your terminal. The moment you're on your phone or away from your desk, you lose visibility and control.

The workarounds people try: SSH into a tmux session (fragile on mobile), set up a VPN and remote desktop (slow), or just hope the agent doesn't get stuck. None of these are actually good.

What I wanted: send a message from Telegram, see the agent's tool calls streaming in real time, and approve or deny actions from my phone.

What OpenACP does

OpenACP is a self-hosted bridge between your messaging platform and your AI coding agent. It uses the Agent Client Protocol (ACP) - an open standard for editor-agent communication - to connect agents like Claude Code, Gemini CLI, and Codex to Telegram, Discord, and Slack.

You (Telegram / Discord / Slack)
  |
OpenACP (bridge + session manager)
  |
AI Agent (Claude Code, Codex, Gemini CLI, ...)
  |
Your Codebase

Everything runs on your machine. No cloud relay, no third party with access to your code, no subscription.

Getting started: Claude Code on Telegram

Install:

npm install -g @openacp/cli

Node.js 20+ required. Claude Code needs to be installed separately.

Then run:

openacp

First run opens an interactive setup wizard. It asks which platform you want (Telegram, Discord, Slack, or all three), your bot token, which workspace directory to use, which agent to default to, and whether to run in foreground or daemon mode.

For Telegram you need a bot token from @botfather. The wizard validates the token and auto-detects your chat ID - no config file editing.

Once running, send any message to your bot. OpenACP creates a session, spawns Claude Code as an ACP subprocess, and streams everything back.

Each session gets its own forum topic. You can run multiple agents in parallel, each in its own topic or thread depending on the platform.

What a session looks like

When the agent is working, you see the tool calls as they happen:

File reads, writes, grep calls, terminal commands - all streamed to your chat. If the agent needs to do something that requires approval, you get inline buttons in the message: Approve or Deny, right there on your phone.

That's the thing that actually solved the lunch problem for me. I can now watch a long task from my phone and unblock it the moment it pauses.

Other agents

OpenACP isn't specific to Claude Code. It works with any agent that supports ACP, which now covers most of the major ones.

To use Gemini CLI from Telegram or Discord, install it the same way - same interface, same streaming:

openacp agents install gemini

Browse everything available:

openacp agents

The list includes Claude Code, Gemini CLI, Codex CLI, GitHub Copilot, Cursor, Cline, goose, Qwen Code, JetBrains Junie, and more. OpenACP pulls directly from the ACP registry, so new agents become available as soon as they register.

Platform support

Telegram, Discord, and Slack are all stable. Each uses platform-native patterns: forum topics in Telegram, threads in Discord, channels and threads in Slack. You can run all three at once pointing to the same agents.

How it compares to the alternatives

Two tools people usually ask about when they see OpenACP:

claude-code-telegram (the original one most people start with) is single-agent, Telegram only, no multi-session support. Fine for the basic use case.

Claude Code Channels is Anthropic's official remote access feature - cloud-based, tied to Claude Code specifically. Not self-hosted.

OpenACP is different in that it supports multiple agents and multiple platforms from one install, and everything stays on your machine. The tradeoff is that you have to self-host it. If that's too much friction, Claude Code Channels is the easier path.

A few practical things

Daemon mode: openacp start runs it as a background service. openacp stop, openacp status, and openacp logs handle the rest.

Tunnels: if an agent needs to expose a local port (say a dev server at 3000), openacp tunnel add 3000 handles it via Cloudflare Tunnel, ngrok, bore, or Tailscale.

Session handoff: if you're working in the terminal and want to continue on your phone, the /openacp:handoff integration transfers the session without losing context. Needs to be set up first with openacp integrate.

Usage tracking: optional token counting and cost reports per session. You can set a monthly budget limit that pauses the agent when hit.

Doctor: openacp doctor checks your daemon, bot token, agent installation, storage, and tunnel config, and tells you exactly what's broken if something isn't working.

Try it

npm install -g @openacp/cli
openacp

Source and issues: https://github.com/Open-ACP/OpenACP
Docs (platform setup guides): https://openacp.gitbook.io/docs
ACP registry (browse agents): https://agentclientprotocol.com/get-started/registry

MIT licensed. I'm a contributor. Happy to answer questions below.

DEV Community: psychomafia.tiger

A clone of our VS Code extension appeared on OpenVSX five days before we open-sourced the repo. It has 5,090 downloads and is using our GitHub OAuth app.

We did not expect to find this

Side by side

The field they forgot

Seven minutes

The part we cannot explain

Inside the .vsix

It gets worse: the clone uses our backend

Where did 5,090 installs come from

The publisher

What we did

What we are asking

How We Built a Chat Layer for GitHub Right Inside VS Code

The alt-tab tax

Why we built it inside the editor and not as a web app

The auth we settled on: VS Code session first, GitHub Device Flow as fallback

Your friends list is already on GitHub

Realtime with Socket.IO and a 30-second heartbeat

What is live, what is next

GitChat vs Live Share vs Copilot Chat

Try it in 30 seconds

How to run Claude Code, Gemini, and Codex side-by-side from Discord

What this setup looks like

Setting up Discord

Installing multiple agents

Running agents side-by-side

How the thread UI works

Continuing or changing agents

A workflow I use daily

Slash commands reference

Things to know

Getting started

How OpenACP talks to 28+ AI agents through one protocol — architecture of a self-hosted messaging bridge

The problem: agents live in your terminal

OpenACP's three layers

Layer 3: how agents actually communicate

Why one protocol means 28+ agents

Quick note: ACP is not MCP

What a session looks like end-to-end

What stays local

Try it

Links

Self-hosting AI coding agents: why it matters and how to do it

What "self-hosted AI" actually means in 2026

The pieces you actually want to own

OpenACP

Why messaging apps instead of a web UI

One install, multiple agents

The daemon side

What stays private

A typical day with this setup

Getting started

Links

How to control Claude Code from Telegram, Discord, or Slack (self-hosted, open source)

The problem

What OpenACP does

Getting started: Claude Code on Telegram

What a session looks like

Other agents

Platform support

How it compares to the alternatives

A few practical things

Try it

Inside the `.vsix`