Two UX issues with Telegram message handling

[mupic]

Problem 1: Sequential message processing breaks multi-message context

When a user sends a task description across multiple Telegram messages (because it doesn't fit in one), the bot responds to each message individually and sequentially. This creates several problems:

• Claude responds to incomplete context mid-stream
• Each intermediate message triggers a full response cycle
• Large tasks that naturally span multiple messages become impossible to describe coherently

Proposed fix: Implement a short accumulation window (e.g. 2-3 seconds). If a new message arrives while the previous one is being processed (or within the window), buffer all messages and pass them to Claude together as a single context block before generating a response.

---

Problem 2: Background tasks block the ability to respond to new messages

When Claude launches a background agent (via run_in_background: true), the conversation context is tied up waiting for the notification. The bot cannot process new messages from the user during this time.

Expected behavior: While a background task is running, the bot should remain available - capable of receiving and responding to new messages in parallel, without being blocked by the running agent.

---

Why this matters: These two issues together make it very difficult to delegate long-running tasks via Telegram. The user can't describe a complex task across messages, and can't interact with Claude while the task executes.

[Nibbler1250]

Thanks for the detailed writeup! We looked at both issues and want to share our analysis — please correct us if we're missing something.

Problem 1 — Multi-message buffering

We think this may be less of a problem in practice than it appears, due to how the current architecture happens to work:

• The Telegram poller batches incoming updates together. By the time Claude finishes responding to message 1 (several seconds at minimum), messages 2 and 3 have already been queued.
• Because every call uses --resume, Claude has the full conversation history when it processes message 2 and 3 — so context is preserved across the sequential responses.

The case where this would genuinely break is if Claude responded in under ~1 second, which doesn't happen. The edge case that could be annoying: user sends msg 1 → Claude responds → user immediately sends msgs 2+3. Those would get separate responses, but the session history still keeps context coherent.

That said, a 2-3 second accumulation window per chatId is clean and well-scoped (~50 lines in telegram.ts). Worth doing if the author can confirm this is a real friction point they're hitting — happy to implement it.

Problem 2 — Background tasks blocking new messages

This one is architecturally deeper. The globalQueue in runner.ts serializes all requests intentionally — parallel Claude sessions with --resume on the same session file would race and corrupt state. Fixing this properly would require either separate session files per concurrent task, or a thread model that doesn't exist in the current architecture.

Risk of regression is high. We'd recommend this be tracked as a separate discussion/design issue rather than a quick fix.

Happy to be corrected on either point if we're missing a use case!

[mupic]

Thanks for the quick feedback and for looking into this so promptly.

Regarding Problem 1:
The issue isn't necessarily that Claude responds too quickly. The main friction occurs because Telegram automatically splits long messages into multiple smaller chunks, especially when large files or attachments are involved. Since each chunk is processed sequentially, it takes a long time to get through them all, and the context often ends up fragmented or lost due to Telegram’s character limits.

Regarding Problem 2:
I agree that this is a complex architectural challenge and not a simple fix. For context, I’ve used a tool called OpenClaw which implements a "sub-agent" model. In that setup, the main session delegates tasks to sub-agents while remaining responsive itself. This allows the user to still interact with the main session — for instance, to cancel a task if it’s no longer needed — while the sub-agent is working in the background.

In the current tool, we have to wait for a task to be fully completed before Claude can read the next message. Adding similar sub-agent or asynchronous functionality would be a fantastic addition to the project.

[TerrysPOV]

Thanks for the detailed issue report, @mupic — both points are well-described.

@Nibbler1250 thanks for the thoughtful analysis, appreciate the continued engagement.

On Problem 1 (multi-message buffering):

Nibbler is right that --resume preserves context across sequential messages — but that's not quite the same as what you're after. Even with full session history, you'd still get three separate responses to three fragments of one task, and the intermediate replies could be confusing or even counterproductive if Claude partially acts on incomplete context. The timing assumption ("Claude takes long enough that messages 2+3 queue up together") also isn't reliable for short messages.

A per-chatId accumulation window (2-3s) would fix this properly. The pattern is clean and well-scoped — we have a similar coalescing mechanism in the Discord handler. If you're up for it, a PR for this would be welcome.

On Problem 2 (background tasks blocking):

The architectural constraint Nibbler describes is real — the queue serialises requests to prevent --resume session corruption. Worth noting though: when Claude launches a background agent with run_in_background: true, the parent process exits quickly after spawning it, so the queue slot frees up faster than it might appear. If you're seeing longer blocking, it may be pre-spawn processing time rather than the background task itself holding the queue.

In the meantime, /fork is the practical workaround — it creates a separate ephemeral session that bypasses the main queue entirely, so you can send follow-up messages while a task is running. Proper parallel session support is a deeper architectural change and probably deserves its own design discussion.

If you'd like to take a crack at both — the accumulation window as one PR and a /fork-documentation or parallel session design as another — that'd be great.

[christian-drescher]

Regarding Problem 1:
If a prompt is too long even for the messenger service to handle it, shouldn't the obvious route be to put the large prompt into an attachment and sent it to the agent, asking it to work on the task attached to the message?

[mupic]

@christian-drescher This tool is used for different purposes, including working with it remotely from a phone. Creating files just to attach them can be quite inconvenient. In general, preparing files simply to hand off work may be unnecessary - it’s often much easier to send the message as is.

[martinvaughn]

There is a new bug where, when a user submits multiple messages at the same time, claudeclaw responds with this message: "Claude is busy - try again in a moment, or use /fork for a quick parallel task." - and the subsequent messages are never sent to the agent.

[TerrysPOV]

@martinvaughn any chance you can document this as anew issue with a repro? It's a bit hard to understand what the exact issue is without.

[TerrysPOV]

@mupic and @christian-drescher I think there is @mupic's issue which needs a specific fix per my post above and I'm hoping @mupic will pick it up and submit a PR. Separately, I really like your idea for long-prompts or copy/paste txts, just like Claude.ai and now ChatGPT.com does. This would be particularly useful for Discord users who are character limited on DMs (unless they subscribe to Nitro). I'll create a new issue for this as an enhancement and if you want to pick that up, that would be great.