Split out from #336 (item C5) — flagged there as containing a security question that may want a different reviewer than the feature work.
Ask: hypervisor agents reading other agents' chats, plus a "link chat" button.
No "link chat" / session-sharing feature exists. But a hypervisor agent can already read other agents' output today, via two MCP paths mounted on every thread (hypervisor_session.py:131):
mcp_dashboard.py:183-189 — get_task_output proxies GET /api/claude/tasks/{id}/output for any task id, no ownership or parentage check. With list_tasks, an agent can enumerate and read any task in the workspace.mcp_agent_orchestrator.py:606-624 — _tool_get_agent_output reads any task dir by id, also unscoped (validates existence, not that the caller spawned it).
Two qualifications: what's readable is the tmux pane output log (mcp_agent_orchestrator.py:169), not a Hypervisor thread's structured event transcript — so an agent can read a Build's scrollback but there is no tool to read another Hypervisor chat's messages, which is what the request actually asks for.
The absence of a scoping check makes today's behavior a de-facto capability rather than a designed feature. If the outcome is "expose cross-agent reading properly" (a thread-transcript read tool + a 'link chat' UI affordance), the same review should decide whether unscoped access-by-task-id is intended, and either bless it explicitly or add ownership/parentage scoping.
Split out from #336 (item C5) — flagged there as containing a security question that may want a different reviewer than the feature work.
Ask: hypervisor agents reading other agents' chats, plus a "link chat" button.
No "link chat" / session-sharing feature exists. But a hypervisor agent can already read other agents' output today, via two MCP paths mounted on every thread (
hypervisor_session.py:131):mcp_dashboard.py:183-189—get_task_outputproxiesGET /api/claude/tasks/{id}/outputfor any task id, no ownership or parentage check. Withlist_tasks, an agent can enumerate and read any task in the workspace.mcp_agent_orchestrator.py:606-624—_tool_get_agent_outputreads any task dir by id, also unscoped (validates existence, not that the caller spawned it).Two qualifications: what's readable is the tmux pane output log (
mcp_agent_orchestrator.py:169), not a Hypervisor thread's structured event transcript — so an agent can read a Build's scrollback but there is no tool to read another Hypervisor chat's messages, which is what the request actually asks for.The absence of a scoping check makes today's behavior a de-facto capability rather than a designed feature. If the outcome is "expose cross-agent reading properly" (a thread-transcript read tool + a 'link chat' UI affordance), the same review should decide whether unscoped access-by-task-id is intended, and either bless it explicitly or add ownership/parentage scoping.