Feature request: supported low-latency navigation to existing Codex Desktop tasks from local apps

What variant of Codex are you using?

Codex in the ChatGPT desktop app on Linux. Installed package metadata reports version 26.901.51231, production flavor. Environment: Manjaro Linux, KDE Plasma, Wayland.

What feature would you like to see?

Please provide a documented, supported way for a local application to bring Codex Desktop forward and select an existing task, with low latency and a completion signal that distinguishes request acceptance from actual UI selection.

Improving the existing codex://threads/<thread-id> path may be sufficient. A narrowly scoped local navigation API would also work. The important outcomes are responsiveness, stable integration semantics, and no modifications to the Codex application bundle.

Use case

I’m building Wayglass, a desktop HUD that lists coding workspaces and tasks. Clicking a Codex task should bring the user directly to that task in the already-running desktop app. This is a frequent manual action, so a pause of around a second is noticeable and makes the click feel unresponsive.

The requested operation is only navigation to an existing task. It should not start a turn, submit a prompt, resume agent execution, or create another task.

Current behavior and reproduction

1. Start the desktop app and open an existing local task A.

2. Have another existing local task B available. Repeat with both tasks already visited in the current session.

3. From a terminal or external launcher, open:

   xdg-open 'codex://threads/<task-b-id>'
   

4. Measure from launching the URL until task B is selected and visibly displayed.

5. Alternate between A and B, recording launcher completion separately from UI selection.

The same delay was reproduced by opening the URL directly, bypassing Wayglass. Wayglass had additional launch overhead that we addressed separately; that did not eliminate the remaining task-switch delay.

Measurements and their limits

In one direct-URL test:

• The launcher returned after approximately 118 ms.
• A screenshot captured before completion still showed task A.
• Codex emitted its selection/follow notification for task B at approximately 1.4 seconds after launch.

Four subsequent warm-switch measurements were:

URL form	Launcher returned	Target task follow notification
Standard task URL	106 ms	801 ms
Standard task URL	120 ms	672 ms
Task URL with hostId=local	139 ms	900 ms
Task URL with hostId=local	172 ms	730 ms

The notification measurement used the existing local thread-stream-following-changed event as a selection proxy. It is not an exact first-painted-frame measurement, nor a claim that this internal event is a supported external integration contract. The screenshot confirms that launcher completion happened before the visible task switch; we do not have frame-accurate paint timings.

The user initially observed 3–5 seconds and later approximately 1–2 seconds. Those are subjective observations; the table above contains the instrumented samples. This is a small local sample, not a controlled performance benchmark, and we have not established behavior on macOS or Windows.

Requested behavior

• Reuse the running desktop app and select the requested task promptly.
• Specify how the destination window is chosen, with an optional window target if multiple windows are open.
• Accept an explicit host identifier so identical or remote task identifiers are unambiguous.
• Distinguish an accepted request from a task that has actually been selected. Ideally expose a documented selected/ready event, with precise semantics about rendering.
• Return clear errors for unknown tasks, unavailable hosts, unsupported capability/version, or no running app. Document whether the operation can launch the app.
• Handle rapid clicks predictably: a superseded slow request should not later replace the task selected by a newer click.
• Keep access local and appropriately scoped; a navigation capability should not require arbitrary JavaScript execution or task-execution privileges.

An illustrative interface could be:

{
  "method": "desktop.navigateToTask",
  "params": {
    "threadId": "<existing-task-id>",
    "hostId": "local",
    "focusWindow": true,
    "requestId": "<caller-generated-id>"
  }
}

This name and transport are proposals, not existing APIs. A documented enhancement to deep links is equally welcome.

Additional information

Possible optimization to investigate

Read-only inspection of the installed navigation code suggests that the task deep-link path awaits a metadata read before navigating, while the app also has an existing task catalog. It may be possible to navigate known tasks using that catalog and let the normal task view perform any required loading or validation.

This is a hypothesis, not an established explanation for all measured latency. We have not profiled the full request-to-paint path or demonstrated an end-to-end speedup from changing that lookup. Any upstream optimization would need to preserve correct host resolution and handling of stale catalog entries, deleted tasks, and unavailable hosts.

A temporary local candidate was prepared and tested in isolation to explore the idea, but it was not installed. We do not want Wayglass installation to patch Codex, depend on minified internal function names, or interfere with application integrity checks and updates.

Illustrative before-and-after code

The following shows the candidate change with readable variable names. The installed JavaScript is minified; this is an explanation of the change, not a proposed public API or a patch intended for users to apply.

Before, the task deep-link callback always asks the app server for task metadata:

readThread: (threadId, options) =>
  getConnection(hostId ?? "local").readThread(threadId, options)

The candidate first checks the existing catalog for the same host and task:

readThread: (threadId, options) => {
  const cached = catalog?.readEntries([
    { hostId: hostId ?? "local", threadId },
  ]);

  if (cached?.length) {
    return Promise.resolve(cached[0]);
  }

  return getConnection(hostId ?? "local")
    .readThread(threadId, options);
}

In the inspected deep-link path, the caller only checks whether this result is non-null before navigating; it does not use the returned object to render messages. This candidate is therefore specific to that navigation callback, not a replacement for general task reads. Catalog entries and full task metadata need not have interchangeable schemas; an upstream implementation could instead make the existence check explicit.

An isolated test against the extracted navigation function confirmed that a catalog hit proceeds without an app-server read and that a catalog miss still performs the existing validation. It did not establish an improvement in live navigation or paint latency. A stale catalog entry could allow navigation to a deleted task, so the normal task view would need to handle that error correctly. The candidate remains uninstalled.

Success criteria

A repeated warm task switch should feel immediate. A proposed target is visible selection within roughly 200–300 ms on a healthy local machine, measured separately from request acknowledgement. This is a requested UX target, not a measured current capability. Cold task loading can take longer, but should provide prompt visible feedback and meaningful completion/error semantics.

Related reports

• https://github.com/openai/codex/issues/25914 — external-client discovery and attachment to the active desktop task. This request is narrower: user-triggered navigation to an already-known task.
• https://github.com/openai/codex/issues/29187 — slow task switching on Windows. Our measurements are from Linux and concern the external task-URL path; we are not asserting the same root cause.

If a supported navigation interface already exists, documentation and a minimal example would address the integration part of this request. Guidance on collecting a request-to-visible-selection trace would also help investigate the performance part.

Additional information

No response

Start with the existing codex://threads/ deep-link handler and the navigation callback that reads task metadata before navigating. Compare its task-catalog lookup with the existing readThread path, then measure launcher acknowledgement separately from task selection. Done means a supported, documented navigation interface with clear host, error, completion, and supersession semantics.