Feature request: support fresh external follow-up and remote chat into the active ACP session

[stefanpieter]

Feature request

Support a true external follow-up / remote chat surface for an active ACP session (for example via Discord), instead of only relying on stale status summaries or one-way notifications.

Problem

When using VS Code + ACP as the main workspace, I may step away from VS Code and follow up from another surface such as Discord.

Right now, the external follow-up experience tends to feel stale because it is based on snapshots/notifications rather than a live connection to the active ACP session.

Two concrete needs:

1. Fresh updates
   • external status requests should reflect the current state of the active ACP session, not an old snapshot
2. True remote chat into the same session
   • I want to be able to message the active Lead/agent from Discord and continue the same VS Code session remotely

Desired behavior

A. Fresh status for active ACP session

If I request an update from an external surface, I want the response to be based on the currently active ACP session:

• current phase / current turn state
• last activity time
• whether the agent is still actively working
• whether the session is waiting for input / blocked / done

B. Remote continuation of the same ACP session

If I reply from an external surface (for example Discord), I want that message to be able to:

• target the currently active ACP session
• continue the same conversation
• deliver the agent's reply back to the external surface
• effectively behave like a remote chat client for the same VS Code ACP session

Why this matters

For multi-step coding workflows, the main VS Code chat is often the canonical session, but the user may need to:

• ask for progress remotely
• nudge the Lead to continue
• answer a question without returning to VS Code immediately

Without a real bridge, external follow-up becomes:

• stale
• one-way
• not trustworthy for active workflow management

Possible implementation directions

Examples of approaches that could help:

• expose the active ACP session as a resumable remote endpoint
• add an extension-managed “active session bridge” abstraction
• distinguish between:
  • notification-only integrations
  • true bidirectional remote chat integrations
• provide an API/event stream for current active-session state

Related issue

This is related to early quieting / incomplete in-progress behavior, but is broader than that issue:

• Cross-posting: updates from one chat can appear in another open chat #19

That issue is about sessions appearing to go quiet too early.
This request is about making external follow-up into the active ACP session a first-class capability.

Additional notes from the original thread

Comment 1

A concrete implementation shape that might make this feature tractable:

1. Separate two modes explicitly

The extension/integration model could distinguish between:

Notification mode

• external surface can request status / receive nudges
• read-only
• no ability to inject messages into the ACP session

Remote chat mode

• external surface can target the currently active ACP session
• user messages are injected into that same session
• assistant replies are mirrored back out
• effectively a remote client for the active VS Code ACP conversation

That separation would make capabilities and expectations much clearer.

2. Introduce an “active session bridge” abstraction

Instead of treating the ACP webview as the only chat surface, the extension could expose a bridge object for the active session, for example:

• active session id
• agent name / display name
• current working directory
• current prompt turn state (idle, running, waiting_for_user, errored)
• last assistant activity timestamp
• recent assistant summary / preview

This would make it much easier for an external integration to ask:

• what session is live right now?
• is it actually busy?
• what happened most recently?

3. Support explicit remote message injection

For remote chat mode, something like:

• sendMessageToActiveSession(...)
• or sendMessageToSession(sessionId, ...)

with clear guarantees around:

• whether a prompt is already in progress
• whether the message is queued, rejected, or interrupts
• how replies are streamed back to the external integration

4. Add clear active-turn semantics

A big part of the stale-update problem is that “last message in storage” is not always the same as “current real state”.

A bridge should expose stronger active-turn semantics such as:

• turn started at
• last update at
• currently receiving chunks or not
• prompt completed / waiting / cancelled / failed

That would make external follow-up much more reliable than polling generic session history.

5. Bidirectional integrations should preserve session identity

The external surface should not create a second parallel chat unless explicitly requested.

Instead, it should attach to the existing active ACP session so the user is still talking to the same conversation/Lead/agent context.

6. Nice-to-have UX

For remote chat mode, useful signals would be:

• “You are talking to active session: / ”
• “Turn in progress — your message will be queued”
• “No active session available”
• “Session is waiting for user input”

That would help users trust the bridge rather than guessing whether it is live or stale.

---

Originally filed by mistake in formulahendry/vscode-acp: formulahendry/vscode-acp#24