[Bug]: Desktop ignores t3code://threads/… deep links the app itself generates (#4996 closed as completed, never merged)

[sensei-woo]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Run T3 Code 0.0.38 on macOS with a local server, and note any thread ID.
2. In a terminal, run:
   open "t3code://threads/primary/<THREAD_ID>"
3. Observe the desktop app.

Expected behavior

The desktop app is focused and navigates to that thread, matching the link
format the app already generates and the mobile app already consumes.

Actual behavior

The app is launched or focused and nothing else happens. The thread never
opens; the user still has to locate it by hand.

This is the exact behavior #4996
("Open a specific desktop thread via t3code://") describes — but that issue is
closed as completed (2026-08-15), while both pull requests that referenced it
are closed and unmerged:
#5071 "feat(desktop): open
threads from deep links" and
#6008 "feat(desktop): open a
thread from a t3code:// deep link". The feature is absent from the shipped
0.0.38 build, so the issue appears to have been closed as completed without
anything landing. Filing this as a bug rather than re-opening the feature
request, since the tracking state and the shipped behavior disagree.

Why the link format is not the problem

The format is real and produced by the app itself. app.asar ships:

export function buildAgentAwarenessDeepLink(input: {
  readonly environmentId: EnvironmentId;
  readonly threadId: ThreadId;
}): string {
  return `/threads/${encodeURIComponent(input.environmentId)}/${encodeURIComponent(input.threadId)}`;
}

and emits it as deepLink on the agent-awareness state. #6008's own description
states that mobile already consumes t3code://threads/<environmentId>/<threadId>
for widgets and notification navigation. macOS registration is also present:
CFBundleURLTypes lists t3code and t3code-dev.

What is missing in the shipped build

Grepping the 0.0.38 app.asar:

• There is exactly one app.on('open-url') listener, and it belongs to the
  Clerk OAuth transport. It acts only on a URL matching its own generated
  redirectUrl and drops everything else; its paired second-instance listener
  does the same, and setAsDefaultProtocolClient is called with
  options.renderer.scheme from that same module.
• The t3code scheme is otherwise only the renderer origin:
  Electron.protocol.handle(scheme, (request) => proxyRequest(request, targetOrigin, contentSecurityPolicy)),
  with DESKTOP_RENDERER_ORIGINS = ["t3code://app", "t3code-dev://app"] used as
  a CORS allowlist.
• No process.argv URL parsing in the main process, and no path from an
  incoming URL to the /$environmentId/$threadId route.

So an incoming deep link has nothing listening for it, which matches the
observed "focus and nothing else".

Impact

Minor bug or occasional failure

Version or commit

0.0.38

Environment

macOS 26.6.2 (darwin arm64), desktop app 0.0.38, bundled Node v24.18.1, local
server on 127.0.0.1

Workaround

Use the web route in a paired browser client — http://127.0.0.1:<port>/primary/<THREAD_ID>
opens the thread correctly. There is no desktop-app equivalent.

Suggested resolution

Re-open #4996 or land a successor to #6008 so the desktop handles the deep-link
format the app already emits and mobile already consumes. A second
app.on('open-url') listener in the bundle is an easy observable signal that it
shipped.

[genr8r]

Confirming this is still present in 0.0.40 (this issue reports 0.0.38).

Checked against the shipped app bundle rather than source:

• The scheme is registered with macOS (CFBundleURLSchemes: t3code, t3code-dev in Info.plist), so the OS routes the URL to the app.
• The desktop main process contains no open-url handler, which is the macOS event an externally fired URL arrives on. Nothing consumes it.
• getDesktopOrigin() returns t3code://app. The scheme's existing role is serving the renderer as an internal asset origin, not routing external links.

Observed behaviour matches the report: open "t3code://<environmentId>/<threadId>" is accepted by macOS and handed to the app, and the app does not navigate.

Use case, in case it helps with prioritisation: a Gmail add-on that creates a T3 thread from an email and wants an "open this thread" affordance on the confirmation card. There is currently no way to link into a specific thread from outside the app. The web route (/<environmentId>/<threadId>) is not a substitute, since a browser is not a paired client and gets redirected to /pair.

Noting #8246 appears to implement exactly this (t3code://app/<environmentId>/<threadId>) and was updated recently.

[Birzool]

One correction and one downstream use case, both from the shipped 0.0.40 bundle.

There is an open-url handler, it just filters. The comment above says the main process contains none. It contains one, registered by the Clerk bridge alongside setAsDefaultProtocolClient:

const openUrlListener = (event: Electron.Event, url: string): void => {
  if (!isMatchingCallbackUrl(url, redirectUrl)) {
    return;
  }
  event.preventDefault();
  handleCallbackUrl(url);
};

second-instance has the same early return. So the URL does reach the app and is then discarded by a guard, rather than arriving nowhere. Practically the same symptom, but it matters for the fix: a second listener has to coexist with the OAuth one rather than replace it, and event.preventDefault() must stay scoped to the URL each listener actually claims.

Observed: open "t3code://app/threads/<environmentId>/<threadId>" exits 0, and log show --predicate 'process == "T3"' records nothing for it. Silent drop, no error path.

Downstream use case: notification click-through. I filed #11866 for local macOS notifications, which the desktop currently does not have at all (agent activity goes to mobile push and Live Activities only). A banner that cannot open the thread it is about makes the user find that thread by hand, which is most of the value gone. #8246 landing would give that click target.

Happy to test #8246 against 0.0.40 if a build is available.

[PetrBrabec]

+1 — adding a concrete use case, since this one is small to fix and unusually valuable for anyone driving T3 Code programmatically.

We run a small "software factory" on top of T3 Code: a control plane queues work, and a local runner opens and resumes threads through the orchestration API (thread.create / thread.turn.start) — one thread builds a plan, a second reviews it read-only, and the builder's own thread is woken again to answer the review. Our dashboard knows every thread id (it created them), and the natural thing is a link on each row that lands in that thread.

Today open "t3code://threads/primary/<id>" focuses the desktop app and stops there, exactly as described above, so the person supervising has to find "<plan> build" vs "<plan> review" by eye among a few hundred threads. The mobile app already honours the same URL, which makes the desktop gap the odd one out.

What would cover it: the desktop open-url / second-instance handler routing t3code://threads/<environmentId>/<threadId> into the existing /$environmentId/$threadId route (and un-archiving or at least revealing the thread if it is archived). Happy to test a build on macOS (currently on Alpha 0.0.40).

[branislavbudzak]

Another concrete use case: a local dashboard that lists unsettled threads from state.sqlite and wants each row to open the exact thread. With the web client blocked by #11710 on packaged builds, t3code://threads/<environmentId>/<threadId> is currently the only way to link into a thread, so #8246 landing would unblock this.

[SpyC0der77]

I am making a t3code pet thing where if i hover over it it lists chats and i want to be able to open the chat i click. (yes it is lil finder guy)

[materemias]

Adding a use case. I maintain CodexBar KDE, a Plasma tray applet that lists running coding-agent sessions from terminals and T3 Code. Clicking a T3 Code row opens t3code://threads/<environmentId>/<threadId>, with both ids read from state.sqlite. On Linux 0.0.44 that only raises the window. If the desktop app routed this link to the thread, a tray applet like this could open the exact thread. So could the Stream Deck integration mentioned in #6008.

[ChrisDott]

+1, with another use case.

I run SketchyBar across three monitors and I've added a T3 Code item to it. It reads state.sqlite and shows a chip for each thread in the active list: running, waiting on an approval or input, errored, or finished. Most of my day is in T3 with several threads going at once, so I want to see from the menu bar when one finishes or needs me.

Clicking a chip runs open "t3code://threads/<environmentId>/<threadId>". On 0.0.45 (macOS) that only brings the window forward. It doesn't switch threads, so I'm back to hunting through the sidebar.

T3 is always already running when I click, so handling links in a running instance would cover my case even without launch-from-closed. I'll switch to whichever link format #8246 lands on.

[b-rennon]

I'm building a bridge between T3 Code and a Work Louder Codex Micro. The keys light up from thread state, and approve, deny and stop go through the WebSocket API. The missing piece is pressing a key to show that thread.

On Nightly 0.0.46 (macOS), open -a "T3 Code (Nightly)" "t3code://threads/<environment UUID>/<threadId>" exits 0 and the visible thread doesn't change. I used the environment's real UUID and an existing thread id.

My workaround raises the app, presses Cmd+K, pastes the thread title and presses Return through System Events. It takes about a second with a visible palette flash, can't tell apart threads with the same title, and needs Accessibility and Automation permission. #8246 would replace all of it.