Side conversations should expose main-thread goals, attachments, and pending messages read-only

Feature request

Side conversations should have a read-only way to inspect the current state of the main thread, including the active /goal, referenced attachments for that goal, and any user messages submitted to the main thread that are still queued while the main thread is busy.

Concrete scenario

A user has a long-running /goal in the main thread. The goal references a specific attachment as the authoritative scope for the work. While that goal is still executing, the user updates or sends an important follow-up message to the main thread. The UI shows that follow-up as queued/pending behind the currently running work.

The user then opens a side conversation to ask whether the side assistant can see the current goal, the referenced attachment, or the queued follow-up and reason about it. Today, the side assistant cannot directly inspect the live/current main-thread state. It only sees inherited context that may be older or summarized, plus anything the user manually pastes into the side conversation.

In practice, this means the side assistant may not be able to verify:

• the current active /goal text in the main thread,
• whether the user already updated that goal,
• which attachment files are currently referenced by the goal,
• whether those attachments are still available to the main thread as active context,
• which follow-up messages are queued behind the running task,
• whether the visible side-conversation context is stale relative to the main thread.

This is especially painful for long-running goals, incident handling, and coordination work where the current goal, referenced attachment, or queued message may contain the newest source of truth.

Attachment visibility gap

This is not necessarily a claim that attachments are being lost. The immediate problem is that the side conversation has no read-only way to confirm the attachment state of the active main-thread goal.

For a long-running /goal that says something like "use this attached .md as the only scope", the side assistant should be able to answer basic verification questions such as:

• What is the active goal text?
• Which attachment(s) does that goal reference?
• Are those attachment references still present in the active goal/session state?
• Can the side assistant read a read-only snapshot of the referenced attachment metadata/content, if the user is already allowed to access it in the main thread?

Without this, the user has to manually paste the attachment path or goal text into the side conversation, and the side assistant still cannot know whether the main thread itself retained the same attachment grounding.

Problem

When a main thread is running a long task, the user can send follow-up instructions that appear queued in that main thread. A side conversation can help triage or clarify the situation, but it cannot currently read those queued messages or directly query the active main-thread goal/state/attachment references. This creates an awkward gap:

• The side assistant can discuss the main task only from older inherited context.
• The user has to manually copy/paste the current goal, queued message, or attachment path into the side conversation.
• The side assistant may give stale or incomplete guidance because it cannot verify what the user already sent to the main thread.
• For attachment-scoped goals, the side assistant cannot tell whether the active goal is still grounded in the intended attachment.

Expected behavior

A side conversation should have a read-only affordance/tool to inspect current main-thread state, for example:

• read_thread(..., include_pending=true, include_current_goal=true, include_referenced_attachments=true)
• a dedicated read_main_thread_state / read_pending_messages / read_goal_attachments tool
• a UI affordance to share the current goal, referenced attachments, and queued messages with the side conversation

This should not allow the side conversation to execute, modify, reorder, delete, or respond to those queued messages. It should also not grant new filesystem or attachment permissions beyond what the user/main thread already has. It only needs read-only visibility so the side assistant can answer questions like "can you see the current goal / attachment / follow-up I queued in the main thread?" without requiring copy/paste.

Why it matters

Side conversations are useful specifically when the main thread is occupied. In that state, the active goal, referenced attachments, and queued follow-ups are often the most relevant source of truth, so hiding them from the side conversation makes coordination harder and increases the chance of stale advice.