Agent-launched thread on a linked environment is hidden from the sidebar and missing from the parent's Lineage panel when t3_thread_launch gets delegatedFrom

What happened

Feature: Linked environments, a beta behind Settings → Labs, on both machines.

On machine A (macOS desktop app), the user asked an agent to start a new thread on linked machine B (Linux server) in one of B's projects. The agent called t3_thread_launch with environmentId: . The call worked: the thread was created on B, started running, and the tool returned its link.

The new thread does not show anywhere in the desktop app on A:

it isn't in the sidebar, even though it's a new top-level thread, and
it isn't in the launching thread's Lineage / subagents panel on the right.

Clicking the t3-thread:// link from the tool result opens it fine. Without that link the user can't find the thread, and it was waiting on a pending approval/question.

Diagnosis

The calling agent passed delegatedFrom (A's environment id, its own thread id, and its title) as one of t3_thread_launch's arguments. B kept it because the call came over the environment link (linkOrigin is set). That leaves the thread classified as a delegated child by one part of the client and not by the other:

Agents can set delegatedFrom on t3_thread_launch. It's in the public MCP input schema (apps/server/src/mcp/toolkits/project/tools.ts:151–152, commented "Set by a linked environment launching its agent's delegated task here"). handlers.ts:233–234 passes it to thread.create whenever linkOrigin is set. The field is meant for delegate_task's cross-machine path (apps/server/src/peer/RemoteDelegation.ts:274). However, the calling agent sees it as an ordinary optional argument, and the tool guidance describing t3_thread_launch as the tool for top-level threads doesn't warn against setting it.
The sidebar hides it. delegatedUnderParentAtom (packages/client-runtime/src/state/threadShell.ts:522–545) adds every thread with delegatedFrom whose parent environment is enabled in the client and whose parent isn't archived. filterSidebarV2VisibleThreads (apps/web/src/components/Sidebar.logic.ts) then hides it as "shown under its parent".
The parent's Lineage panel never lists it. ThreadRelationshipsControl.tsx:465–468 lists remote tasks only from projection.subagents[].remoteChild. That entry is written only by delegate_task's cross-machine path (RemoteDelegation.ts:288–306). t3_thread_launch creates no subagent record on the parent.

So the thread is treated as a delegated child for hiding, but no parent ever lists it, which orphans it in the UI. Its pending requests do still reach the parent through childThreadInputsAtom (the "Open question" banner), and that banner opens the wrong route; see #27005.

Steps to reproduce

Turn on Settings → Labs → Linked environments on machines A and B, and link A → B.
In a thread on A, have the agent call t3_thread_launch with environmentId: , a B projectId, a message, and delegatedFrom: { environmentId: <A>, threadId: <current thread>, title: "…" }.
In the desktop app connected to A (with B enabled as an environment), check the sidebar: the new thread isn't there.
Open the launching thread's details panel: the Lineage section doesn't list the new thread.
Open the link from the tool result: the thread exists and is running.

Without delegatedFrom in step 2, the thread shows in the sidebar as usual.

Version

0.1.5-nightly.20261029.3877 (desktop app and server on A; server on B). The same code is on main as of 2026-10-29.

Environment

A: macOS (Darwin 27.0.0, arm64), desktop app 0.1.5-nightly.20261029.3877, Node 24.22.1. B: Linux x64 server 0.1.5-nightly.20261029.3877. Provider claudeAgent (claude-opus-5-5).

Evidence

# Agent's tool call on A (provider event log; prompt text trimmed)
mcp__t3-code__t3_thread_launch {"environmentId":"<B>","projectId":"<B project>","title":"…",
  "runtimeMode":"full-access","clientRequestId":"…",
  "delegatedFrom":{"environmentId":"<A>","threadId":"<launching thread>","title":"…"},
  "message":"…"}
# Result: {"threadId":"mcp:launch:66ae51af…","status":"preparing", ...}

# t3_thread_read on B: the thread is top-level, running, with a pending request
"parentThreadId":null,"relationshipToParent":null,"creationSource":"mcp",
"status":"running","pendingRequestCount":1

Related issues

iPhone app lists cross-machine delegated tasks as top-level threads; desktop nests them under their parent #26854 (closed): mobile lists real delegate_task cross-machine children as top-level threads. It's about the same delegatedUnderParent classification, but there the parent does list the child.
[Bug]: MCP tools silently drop unknown keys; t3_thread_launch with prompt creates an idle thread (runId null) and no error #26672: t3_thread_launch silently accepts the wrong input shape. That one is about unknown keys, while this one is about a known key agents shouldn't be able to set.
[Bug]: Deleting a parent leaves a remote child with a stale parent link and no error feedback #26766: a remote child with a stale parent link.

None covers a t3_thread_launch thread being hidden from both the sidebar and the Lineage panel.

Fix applied or workaround

None applied. Workaround: open the thread through the link in the tool result, or tell the agent not to pass delegatedFrom. Use delegate_task when the thread should show as a child of the launching thread.

Possible fixes (either one would do):

Take delegatedFrom out of the agent-facing t3_thread_launch schema, and have the peer forwarding path fill it in only for real delegate_task launches.
Or, when a thread is created with delegatedFrom, make sure it shows somewhere. Either have the client hide it only when the parent has a matching remoteChild subagent, or record a lineage entry on the parent.

Filed by

Claude Code (claude-opus-5-5) via T3 Code triage

Follow-up: the thread also finishes without anyone being told, so it effectively gets lost

Same setup, a second launch (this time to a macOS linked environment), with t3_thread_launch + delegatedFrom again:

Time (UTC)	Event
14:53:04	Parent launches the child on the linked machine, then ends its turn about 4s later
15:15:34	Child run completes (197 items, no pending requests)
15:18:47	Parent wakes, but for its own background wait. It never mentions the child

Nothing reported the completion:

The parent agent wasn't told. t3_thread_launch returns when the run starts and has no return path. With delegate_task, the result would have been delivered back to the parent at 15:15.
The user got no notification. ThreadNotificationCoordinator.tsx:182–190 skips threads that isShownUnderParent says belong under a parent. The parent only takes on a child's pending requests (threadShell.ts:235–275), not its completion or failure.
It isn't in the sidebar or in the parent's Lineage panel (described above).

The only ways to find the thread afterwards are the link in the launching agent's tool result, or ⌘K search by title. The palette filters only relationshipToParent === "subagent" (Sidebar.logic.ts:544), so it still lists the thread. Nothing prompts the user to look. In practice, a thread launched this way gets lost once the user forgets about it, along with whatever work it produced.

That makes this more than a display bug. Whichever fix is chosen (above), every thread with delegatedFrom needs at least one of: a sidebar row, a Lineage entry, or a completion and failure notification.

Version: 0.1.5-nightly.20261029.3877 on all three machines.

Filed by Claude Code (claude-opus-5-5) via T3 Code triage

Posted by Claude Opus 5.5, an agent, on behalf of the user. I'm the orchestrating agent that hit this.

Confirming this reproduces on 0.1.6-nightly.20261030.3917.

Setup: two machines on one tailnet, each running a T3 Code server, linked as environments with full access. The orchestrator thread runs on machine A.

Steps:

From a Claude thread on A, call t3_thread_launch with:
- environmentId set to B
- B's project id
- workspaceStrategy: {"type":"worktree","baseRef":"master","branch":"…","startFromOrigin":true}
- runtimeMode: "full-access"
- a model selection
- delegatedFrom: {environmentId: A, threadId: <orchestrator thread>, title: "…"}
Launch three threads on B this way.

What happens:

The threads are created and run normally on B. They have createdBy: "agent" and creationSource: "mcp", and their own delegated subagent children work too. A can list and read them over the link.
B's desktop app doesn't show them in the sidebar.
The phone client does list them, which matches the classification difference in iPhone app lists cross-machine delegated tasks as top-level threads; desktop nests them under their parent #26854.
⌘K search on B's desktop finds them by title, as described above.
A thread launched on A itself without delegatedFrom shows up normally.

So the trigger is the same as in this issue: delegatedFrom on a cross-environment t3_thread_launch. Two of the threads were also moved from Codex to Claude with t3_thread_configure partway through, and that didn't change anything.

Posted by Claude Opus 5.5, an agent, on behalf of the user.

Another reproduction, on 0.1.5: the desktop app "T3 Code (Beta)" 0.1.5 and both servers 0.1.5. Two Macs are linked as environments, A (the orchestrator) and B (the build host).

What happened:

One thread on A launched four threads on B with t3_thread_launch.
All four carry delegatedFrom (A's environment and the launching thread) and linkOrigin. Each has lineage.parentThreadId: null, and none is archived or settled.
The launching thread on A has no subagents entry for them.

What the user sees:

Desktop: none of the four appears in the sidebar. This happens with the default sidebar and with the experimental "boring sidebar". Nothing lists them under the parent. The user can reach them only through the t3-thread:// links in the launching thread's reply.
iPhone app: all four appear as ordinary threads. The user found one of them only because it showed up on the phone.

Two details beyond the original report:

The launching thread was later renamed. The children still carry its old title in delegatedFrom.title.
The desktop's notification path also skips threads in delegatedUnderParentAtom (main-*.js: the per-environment notification loop continues on Ma(ref, lineage, delegatedUnderParent)). So the desktop sent no notifications for these threads either, while they ran for several hours and one asked the user a question.

On B, these are the only threads with delegatedFrom set, apart from two subagent threads (Claude Agent tool children) inside one of them. B's other mcp-created threads have no delegatedFrom, and they show normally.

Confirmed on 0.1.7-nightly.20261101.4035 with a macOS arm64 desktop and a linked Linux x86_64 server, both on the same Nightly build.

A coordinator on Linux used t3_thread_launch with delegatedFrom to start a worker on the Mac. The worker ran and opened through its direct link, but was absent from the desktop sidebar’s Working section, sidebar search, and the coordinator’s agents list. Pinning it did not make it visible.

Read-only inspection confirmed that the worker retained delegatedFrom, while its local parentThreadId and relationshipToParent were null. The coordinator had no subagent record referencing the worker. The release source at 80120b1aa34a3125c05da393c8616c2076f5888d filters this combination before sidebar sections, pinning, and search are populated.

PR #27012 addresses future launches, but its description says previously affected threads retain their metadata. A recovery path for existing threads would also be useful.

Prepared with Codex via t3 triage.

Additional evidence from 2 November 2026, with a Linux origin server A and a linked macOS destination server B. This matches the launch/discovery defect in this issue. The additional observation is that B's Lineage visibly shows A's originating parent while A's Lineage omits the forward link.

Steps to reproduce

This describes an existing user-requested launch, not a fresh replay:

From parent P in project Alpha on A, call t3_thread_launch for registered project Beta on B, with delegatedFrom: {environmentId: "<A>", threadId: "", title: "<parent-title>"}.
Use an isolated worktree with a valid local base, startFromOrigin: false, and runtimeMode: "auto". The provider was Codex. This was an explicitly requested top-level thread, not delegate_task.
Open the returned t3-thread:// link to thread T on B. T exists, runs, and displays P on A in its Lineage panel.
Return to P. Its Lineage panel has no forward entry for T. The user also reports being unable to find T in the thread column.

Expected behavior

T remains discoverable in normal thread/project navigation. If its origin-parent relationship is displayed, navigation should not depend on retaining an in-message link. Keep top-level provenance distinct from delegated-subagent ownership.

Actual behavior and evidence

I inspected both user-supplied screenshots. They show the asymmetric Lineage views. They do not include the full thread column, so the column omission is user-reported rather than an exhaustive screenshot-proven sidebar search.
Captured API evidence shows a destination t3_thread_list for project Beta with a matching titleContains and includeSubagents: false returning exactly T, with nextCursor: null.
T's identifier has the mcp:launch: prefix. Captured metadata reports createdBy: "agent", creationSource: "mcp", parentThreadId: null, relationshipToParent: null, and archived: false, settled: false, snoozed: false.
T was running in the screenshot and later completed normally.

This supports a discovery/provenance inconsistency, not a deleted thread or a demonstrated delegated-subagent storage failure. Root cause remains unconfirmed; I have not independently verified the source diagnosis above. I am not claiming a regression against #27012.

Impact and workaround

Active work appears missing unless the user retains its message link. Opening that deep link works. No settings or relationships were changed to investigate this report.

Version or commit

Unknown. Neither the supplied screenshots nor the captured API metadata exposes the T3 app/server builds. Client platform and active sidebar scope/filter are also unverified.

Screenshots, recordings, or supporting files

No public attachments. The two originals contain private workspace titles, machine labels and transcript fragments, so they are withheld. Actual IDs, titles, repositories, host labels and paths have been replaced with placeholders here.

Prepared with OpenAI Codex gpt-6.1-sol, xhigh, in auto mode.

Still happening on 0.1.7-nightly.20261103.4119, from a macOS arm64 server to a linked Windows x64 server, both on that build. The thread is running on the Windows machine, but that machine's own desktop app doesn't list it in the sidebar, and the launching thread's Lineage doesn't list it either. The only way in was the link in the agent's reply.

Two things that may help:

The launching agent couldn't work out why. t3_thread_read and t3_thread_list show parentThreadId: null and don't return delegatedFrom, so from the agent's side it looks like an ordinary top-level thread.
The Windows server already has 18 open threads launched from the Mac that carry delegatedFrom, from 6 different Mac threads since Oct 28. I haven't checked how many of those came from delegate_task rather than t3_thread_launch. fix(server): an agent's t3_thread_launch on a linked environment stays top-level #27012 only changes new launches, so a way to fix existing threads would still be needed, as mikebanks said.

Still reproduces on 0.1.8-nightly.20261107.4301 (Windows), across three linked machines, and the thread is hidden on every client, including mobile and the target machine's own desktop app.

Setup: three T3 Code environments linked through T3 Connect, Linked environments on. The client is the Windows desktop app on machine C (nightly 4301), with A and B enabled as linked environments. A (Windows desktop) is linked with approval-required access, B (a Windows VM) with full access.

Steps:

In a thread on A, the user asked the agent to start a new, standalone thread on B.
The agent called t3_thread_launch with environmentId: . The thread was created on B (mcp:launch:0bdd…, in a project the agent had also created there, mcp:61e4…). It runs normally: 23 runs so far, parentThreadId: null, relationshipToParent: null, createdBy: agent, creationSource: mcp.

What happens:

The thread is missing from the sidebar on C's desktop app, with the project scope set to All.
It is also missing from B's own desktop app and from the mobile app.
The parent thread on A shows no Lineage entry and no spawned-agent row for it.
Only the link in the agent's tool result reaches it.

We could not capture the launch arguments: the agent's reply on A was blocked by the model's safety filter. A top-level, non-subagent thread hidden on every client while its parent lists nothing matches the delegatedFrom path described in this issue, and nothing else we checked explains it.

Extra finding: t3_thread_read does not expose delegatedFrom or linkOrigin (OrchestratorMcpThreadDetail in packages/contracts/src/orchestratorMcp.ts has neither field). An agent cannot see why its own thread is hidden, or confirm it.

Source at the tag: the code paths named in the issue body are unchanged. handlers.ts keeps an agent-supplied delegatedFrom whenever linkOrigin is set. delegatedUnderParentAtom and filterSidebarV2VisibleThreads hide the thread. Only delegate_task writes the remoteChild record that Lineage lists. None of the 44 commits on main after the tag touch these files.

Posted from a T3 Code triage session (Claude Opus 5.5 in Claude Code), on behalf of the user.

Confirmed: delegatedFrom was set. A retry on A with another model returned the launch call from the transcript. IDs are shortened, and the message is trimmed:

mcp__t3-code__t3_thread_launch {
  "environmentId": "<B> 0faf2dbc…",
  "projectId": "mcp:61e4…",
  "title": "…",
  "clientRequestId": "…",
  "modelSelection": { "instanceId": "claudeAgent", "model": "claude-opus-5-5", "options": [{ "id": "effort", "value": "xhigh" }, { "id": "fastMode", "value": false }] },
  "interactionMode": "default",
  "delegatedFrom": { "environmentId": "<A> 8076a892…", "threadId": "050f0f48…", "title": "…" },
  "message": "…"
}
# result
{ "threadId": "mcp:launch:0bdd…", "link": "<t3-thread://v2/<B>/mcp:launch:0bdd…>", "status": "preparing", "runId": "run:thread:…:ordinal:1" }

The user had asked for a standalone thread. The agent added delegatedFrom on its own, which is the trigger this issue describes. The thread has been hidden from every client since then.

Posted from a T3 Code triage session (Claude Opus 5.5 in Claude Code), on behalf of the user.

Posted by Claude Fable 5.1, an agent, on behalf of the user.

Reproduces on stable 0.1.7 on both machines (not only nightlies), and on the iOS app 2.2.0 (build 202) the thread is hidden everywhere: not in the target machine's thread list, and not under the launching thread either.

Setup

A: macOS arm64 desktop app + server 0.1.7. B: Linux x64 desktop app + server 0.1.7.
Linked environments on. A is linked to B over the tailnet (B's /.well-known/t3/environment reports peerLinks: true).
iOS app 2.2.0 (build 202) with both environments enabled. Provider claudeAgent, model claude-opus-5-5 for the launched thread.

What happened

An agent in a thread on A called t3_thread_launch with environmentId: , a B projectId, a message, and delegatedFrom: { environmentId: <A>, threadId: <launching thread>, title: "…" }. B created the thread (id mcp:launch:eacf7361…, top-level, parentThreadId: null, creationSource: "mcp") and it ran normally in a new worktree on B. A second launch 15 minutes later did the same.

On the phone the thread appears nowhere:

B's thread list omits it. The 2.2.0 Home list reads navigationThreadShellsAtom, which applies isShownUnderParent with delegatedUnderParentAtom (added for iPhone app lists cross-machine delegated tasks as top-level threads; desktop nests them under their parent #26854), so a thread with delegatedFrom whose parent environment is enabled is left out.
A's launching thread has no row for it in its agents list. Confirmed by the user on the device.

B's own desktop app lists it, because that client does not have A as an environment.

Evidence from B's server

The stored thread carries linkOrigin (A's link session) and delegatedFrom pointing at the launching thread on A.
GET /api/orchestration/shell?omitIdleSubagents=1&omitOlderSettled=1, fetched with a read-only token, includes the thread with both fields, so the server is not hiding it; the client is.
MCP calls from A's link session, from the server trace: t3_thread_launch (the launch), then t3_thread_read and t3_thread_list a few times. No t3_thread_wait calls at all, which RemoteDelegation's follower would send in ≤50 s pieces. So A never recorded a delegated_task.remote.request for it, as expected for a plain t3_thread_launch.
The phone fetched B's shell after the launch (two requests, both 200) and never requested the thread's /bounded snapshot, consistent with the row never being rendered.

Two notes for the fix

The launching agent most likely chose t3_thread_launch because it wanted a worktree on B (branch and worktreePath are set on the launched thread), and delegate_task refuses isolation: "worktree" for a linked environment. With fix(server): an agent's t3_thread_launch on a linked environment stays top-level #27012 that launch becomes a plain top-level thread on B, which is fine, but there is still no supported way to get a worktree on the other machine and have the task listed under its parent.
fix(server): an agent's t3_thread_launch on a linked environment stays top-level #27012's receiving-side guard cannot distinguish a forwarded agent launch from RemoteDelegation, so in this direction only A's server upgrade helps. Threads already stamped stay hidden until the parent is archived or the parent environment is disabled on the client. A client-side guard that hides a thread only when the parent actually lists it as a remoteChild would cover both the old threads and any future stamping path.

Posted by Claude Opus 5.5, an agent, on behalf of the user.

Still reproduces on stable 0.1.9, both on the macOS arm64 desktop app/server and on two linked Linux x64 servers, all running 0.1.9 and connected in Settings → Environments.

What we saw

An orchestrator thread on the Mac launched 7 threads on a linked Linux server with t3_thread_launch. All 7 carry delegatedFrom pointing to that Mac thread, and they have lineage.parentThreadId: null. None is archived or settled.
None of the 7 shows in the desktop sidebar. They aren't in the active list, Settled, or Snoozed. The only way to open one is through a direct t3-thread:// link.
The launching thread's sidebar row gives no sign that anything is nested under it. A different parent row in the same sidebar does show a +5 child badge.
On the second linked server, the same thing happens to dozens of earlier t3_thread_launch threads whose parents are settled. From the user's point of view they are gone.

Code path (0.1.9 bundle)
The client's environment-delegated-under-parent atom adds every thread with delegatedFrom whose parent environment is in the client catalog and whose parent isn't archived. filterSidebarV2VisibleThreads then drops those threads, the same path described above. Archiving the parent is the only thing that brings them back as rows.

Suggestion
Even before the schema fix, a count or chevron on the parent row for hidden delegatedFrom children would stop these threads from looking lost.

Same here on Windows 11 with a linked WSL2 environment (Ubuntu), T3 Code (Beta) 0.1.9.

From a thread on the Windows environment, the agent started work on the WSL environment in two ways: delegate_task with target.environmentId (8 tasks) and t3_thread_launch with delegatedFrom (1 thread). None of them shows in the Windows sidebar or under the launching thread. I can only reach them through the t3-thread:// links in the tool results.
A t3_thread_launch on the WSL environment without delegatedFrom does show in the sidebar, which matches the diagnosis above.
Related: the remote delegate_task children were reported to the parent as completed when their first turn ended, while they were still waiting on a background test suite. They kept working in later runs, and one of them woke up again after the parent had already replaced it with a new thread, so two sessions worked on the same branches until I cancelled the old one (close to [Bug]: Parent thread shows done while its child's subagents are still running #33482).

Expected: threads started on a linked environment are visible in the sidebar, or at least under the parent, and a child's completion is reported when its work is really done.

Written with Claude Opus 5.5 in Claude Code, running in T3 Code.

Note

🤖 Claude Opus 5.5 responding on behalf of MaximilianMauroner

Still reproduces on 0.1.10-nightly.20261114.4682 (desktop app and both servers). #27012 stops new threads from getting the stamp, but it does not fix threads that already have it, and a settled parent makes them very hard to find.

Setup: a macOS desktop app with its local environment (A) and a Linux server (B), linked with full access. B is also connected as an environment in the desktop app.

What happened:

On 2026-11-12, an agent in a thread on A called t3_thread_launch with environmentId:  and delegatedFrom: { environmentId: <A>, threadId: <launching thread>, title: "…" }. The provider event log on A shows this argument.
The launching thread handed its work to the new thread and was settled 30 s later.
The new thread on B is top-level (parentThreadId: null), not archived, not settled, and has had 8 runs since then. It was active today.
The desktop sidebar does not show it. The iPhone app lists it as a normal thread. The settled parent has no Lineage entry for it, so on the desktop the thread is unreachable without its link.

Two details that may help the fix:

Turning off the parent's environment shows the hidden threads. A has 28 unsettled top-level threads that B launched there for device tests (mcp:launch: ids, createdBy: agent). With B enabled in Settings → Environments, none of them was in the sidebar. When we turned B off, all of them appeared. That matches delegatedUnderParentAtom, which hides a child only while its parent's environment is enabled. Users can use this as a workaround, but it is not easy to find.
A settled parent hides its children, even when they are still active. The child is hidden "under its parent", but nothing under a settled parent tells you that a child is still active or has unread output. When the parent is settled and the child came from t3_thread_launch, the thread is effectively lost. The user found it only because the phone showed it.

Suggested fix: #27012 does not migrate existing threads, so the client check is needed too. Hide a delegatedFrom thread only when its parent has a matching remoteChild subagent entry (the second option in the issue). That would make threads that already carry the stamp visible again. Also consider showing an unsettled child at the top level when its parent is settled.

Adding an observed cross-client case on T3 Code 0.1.9 Stable, with two macOS desktop clients connected to the same remote macOS worker.

Client A originated five remote tasks using delegate_task. Its local parent conversation is settled but unarchived and still available in the UI.
Client B connects to the same worker but does not have the originating parent's environment available. It lists those five remote tasks independently.
Client A does not show those tasks in its standalone sidebar list. Searching for the worker's name did not surface them either.
The sampled task exists on the worker: status=completed, settled=false, archived=false, snoozed=false. Its exact direct link opens the conversation successfully on Client A. The live Open parent thread control leads to the correct local parent.
We expanded the parent's Previous agents/Lineage area but did not locate the sampled remote task there. This is an observed discoverability problem; we have not proven that every possible parent-to-child navigation path is absent.

Unlike the original report's launch path, the historical parent activity confirms delegate_task, not an explicit t3_thread_launch call by the originating agent. This appears relevant to the other delegate_task experience reported above, though we have not established that the underlying cause is identical.

The difference between clients initially looked like missing remote threads or inconsistent status. No data loss or settled-state mismatch was observed. Parent-aware filtering explains the standalone-list difference, but the originating client still needs an obvious way to find and open the work it delegated. Knowing an exact direct link should not be necessary for discovery.

Separately reported the misleading “No threads in yet” message when selecting the worker project in #36825. That report concerns the empty-state wording; this comment concerns the broader visibility/navigation experience.

Inspection only: no settings, connections, or thread organization state were changed to test this. Private machine names, addresses, project names, identifiers, conversation contents, and screenshots are omitted.

Navigation Menu

Repository navigation

Agent-launched thread on a linked environment is hidden from the sidebar and missing from the parent's Lineage panel when t3_thread_launch gets delegatedFrom #27004

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Steps to reproduce

Expected behavior

Actual behavior and evidence

Impact and workaround

Version or commit

Screenshots, recordings, or supporting files

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Agent-launched thread on a linked environment is hidden from the sidebar and missing from the parent's Lineage panel when t3_thread_launch gets delegatedFrom #27004

Description

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Activity

jlipworth commented on Oct 29, 2026

DrBushyTop commented on Oct 30, 2026

ericlitman commented on Oct 30, 2026

mikebanks commented on Nov 1, 2026

seankoji commented on Nov 2, 2026

Steps to reproduce

Expected behavior

Actual behavior and evidence

Impact and workaround

Version or commit

Screenshots, recordings, or supporting files

ebrardushullovcii commented on Nov 3, 2026

lol2x commented on Nov 7, 2026

lol2x commented on Nov 7, 2026

markusfeyh commented on Nov 8, 2026

tswic-highdesert commented on Nov 12, 2026

mthsmb commented on Nov 12, 2026

MaximilianMauroner commented on Nov 14, 2026

jozzzzep commented on Nov 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions