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

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.

Reproduce the macOS deep link with the documented open "t3code://threads/primary/<THREAD_ID>" command, then inspect the desktop main-process app.on('open-url'), second-instance, and setAsDefaultProtocolClient entry points alongside the renderer thread route. Done means an incoming link focuses the app and navigates to the specified environment and thread, with behavior verified in the desktop build.