Feature request: run prompts concurrently in different sidebar chats

[stefanpieter]

Feature request

Support running prompts concurrently in different Hermes sidebar chats inside one VS Code window.

Problem

The extension can store and switch between multiple chat histories, but it currently behaves like there is only one live Hermes/ACP runtime for the whole sidebar.

A desired workflow is:

1. Start a long-running task in Chat A, for example implementation work.
2. Switch to Chat B while Chat A is still running.
3. Ask a separate prompt in Chat B, for example a review, research question, or unrelated small edit.
4. Let both prompts continue independently, with their own output streams, tool activity, cancellation controls, and completion state.

Today this does not appear to be supported. From the current extension shape in joaompfp.hermes-ai-agent@3.2.2:

• SessionManager is documented as managing a single active ACP session.
• ChatPanelProvider has one global busy flag and one global messageQueue.
• When a message is sent while busy, the extension queues it and calls session.cancel(), effectively interrupting the current prompt instead of running a second chat concurrently.
• There is one shared lastTurnText, lastTurnTools, and active SessionManager, so concurrent updates from different chats would be unsafe without additional routing/state isolation.

Desired behavior

Within the same VS Code sidebar, different chats should be able to run independently:

• Chat A can remain active/running after the user switches away from it.
• Chat B can start a new prompt while Chat A is still running.
• Each chat shows its own running/done/error state in the session list.
• Streaming assistant text and tool updates are routed to the correct chat by session/chat identity.
• Cancel/Stop only affects the selected chat, or clearly offers a per-chat/global choice.
• Queuing is per chat, not global to the entire sidebar.
• Switching between chats should not reset, cancel, or corrupt the other chat’s active run.

Possible implementation direction

The safer design is likely per-chat live runtime state, for example:

• each chat has its own SessionManager, busy state, queue, output buffers, pending tool metadata, and ACP session id; and
• either each concurrently running chat gets its own hermes acp subprocess, or the extension implements a robust single-process session router that can safely handle multiple concurrent session/prompt calls and route session/update notifications by sessionId.

A one-ACP-subprocess-per-running-chat model may be simpler and safer initially because it avoids interleaved update/cancellation hazards, but it should expose resource trade-offs clearly.

UX considerations

Suggested UI details:

• show running indicators in the chat/session list;
• show which chats are idle, running, queued, done, errored, or cancelled;
• allow switching to a running chat to see live output;
• warn if two running chats may edit the same workspace files;
• optionally limit maximum concurrent chats to a configurable number;
• optionally suggest separate git worktrees for concurrent code-editing tasks;
• make per-chat Stop/Cancel behavior explicit.

Acceptance criteria

• The user can start a prompt in Chat A, switch to Chat B, and start another prompt without cancelling Chat A.
• Chat A and Chat B stream their own outputs into their own histories.
• Tool calls and file-open behavior are attributed to the correct chat.
• Cancelling Chat B does not cancel Chat A, and vice versa.
• Closing/reloading VS Code does not leave the UI in a misleading state for any still-running or orphaned chats.
• If true concurrency is unavailable because of ACP/Hermes backend constraints, the UI should say so explicitly and avoid silently interrupting the active chat.

Related but distinct issues

This is related to, but not covered by:

• Feature request: support fresh external follow-up and remote chat into the active ACP session #8 — remote chat/follow-up into the active ACP session;
• Feature request: support steering and interrupting active chat/actions mid-run #13 — steering or interrupting one active chat/action mid-run;
• Feature request: preserve ACP chat history across VS Code restarts #11 — preserving chat history across restarts.

This request is specifically about multiple different sidebar chats running prompts concurrently in one VS Code window.