Forem: psychomafia.tiger

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.