Managing Multiple Terminal Sessions From Telegram

Running Parallel AI Agents

Modern development often involves multiple parallel tasks: one AI agent refactoring the backend, another generating frontend components, a third running the test suite. Remocode lets you manage all of these from a single Telegram chat.

Terminal Naming Strategy

Every Remocode terminal can be given a name. These names are how you target specific sessions from Telegram. When running multiple terminals, thoughtful naming is essential.

Good naming conventions:

• ●By component: api, web, mobile, db
• ●By task: refactor, tests, deploy, debug
• ●By project-component: shop-api, shop-web, blog-api

Keep names short. You will type them on a phone keyboard, often one-handed. Single words or short hyphenated pairs work best.

Checking Status Across Sessions

The status command accepts an optional terminal name:

status

Without a name, it reports on the default or most recently active terminal.

status api

With a name, it generates an AI-powered progress report for that specific session. To check all your running sessions, send status commands for each:

status api
status web
status tests

Each response tells you what the agent in that session has accomplished, what it is currently doing, and whether it needs input.

Switching Between Sessions With Via Mode

Via mode connects you to one terminal at a time. To switch sessions:

• ●Exit the current session: !exit
• ●Connect to the new session: via web

There is no shortcut to switch directly. You must exit first, then enter the new session. This is intentional — it prevents accidental input going to the wrong terminal.

Handling Questions From Multiple Sessions

Question detection works across all terminal sessions simultaneously. When an agent in any session asks a question, it is forwarded to your Telegram chat with the terminal name included in the message. You can respond to questions from different sessions without entering via mode.

This means you might receive a question from the "api" session, followed by a question from the "web" session, and you can answer both independently using the inline buttons. The responses are routed to the correct terminals automatically.

Alert Management

Error alerts also include the terminal name, so you always know which session encountered an error. When you receive an alert, decide your response based on severity:

• ●Low severity (a single test failure, a warning): Check later with status <name>.
• ●Medium severity (build failure, dependency error): Send reply_3 for context, then decide.
• ●High severity (segfault, permission denied in production): Enter via <name> immediately.

Practical Multi-Terminal Workflow

Here is a real-world scenario managing three parallel sessions:

Morning setup:

• ●Terminal "api": Claude Code refactoring the user service
• ●Terminal "web": Gemini CLI building a new dashboard page
• ●Terminal "tests": OpenAI Codex writing integration tests

Midday check-in from phone:

• ●status api — Claude finished the refactor, waiting for test confirmation. You answer the forwarded question.
• ●status web — Gemini is still working, no questions pending.
• ●status tests — Codex hit a failing test. You send reply_3 to see the context, then via tests to provide debugging guidance.

Afternoon:

• ●Alerts arrive for a TypeError in the "web" session. You check status web, see Gemini already fixed it, and continue with your day.

Avoiding Confusion

The main risk with multiple sessions is sending input to the wrong terminal. Mitigations:

• ●Always check which via session you are in before typing.
• ●Use !exit before switching.
• ●Use question buttons (which are automatically routed) instead of via mode when possible.

With disciplined naming and the layered monitoring approach (alerts, questions, status, via), managing multiple parallel AI agents becomes a structured, manageable workflow.