Codex Desktop: keep active tasks visible in a persistent sidebar section

Open 💬 3 comments Opened Jul 17, 2026 by vorojar

What variant of Codex are you using?

Codex Desktop app

What feature would you like to see?

When the sidebar contains many projects and tasks, it becomes difficult to find a task that is still running—especially when several tasks are active across different projects at the same time.

Today, active tasks are mixed into the normal project/thread hierarchy. They may be outside the visible scroll area or hidden inside a collapsed project, so checking progress often means scanning multiple projects and long task lists.

Please add a persistent, global Active tasks section to the sidebar. For example, it could be pinned at the bottom (or top) of the sidebar and remain visible while the rest of the task list scrolls.

Suggested behavior:

Show every task/thread with a currently running turn, across all projects.
Keep the section visible even when its project is collapsed or outside the current scroll position.
Clicking an item should immediately navigate to that task.
Show a compact state such as running, waiting for approval/input, or reconnecting.
Remove the item when the turn reaches a terminal state.
If there are no active tasks, hide or collapse the section.

The exact placement is flexible; the important part is having a stable, one-click way to locate all in-progress tasks.

Why this matters

Codex encourages parallel, long-running work. A typical workflow may have several tasks running in different projects while the user continues working elsewhere. In a crowded sidebar, the tasks that need attention are harder to find than completed history.

A persistent active-task area would turn the sidebar into a lightweight task monitor and make parallel sessions much easier to supervise without changing the existing project organization.

Expected behavior

At any time, I can see all currently active tasks in one stable sidebar location and jump to any of them with one click, regardless of project, sidebar scroll position, or whether the project is collapsed.

Additional information

This is specifically about discoverability and navigation for active tasks in the Desktop app, rather than general thread pinning or multi-window support.

I searched for existing issues around active/running sessions, sidebar navigation, pinned tasks, and multi-task workflows. I found related requests such as #33205 (multi-window workflows), but not this persistent active-task switcher request.

View original on GitHub ↗

3 Comments

LhhMiracle · 1 month ago

Adding a concrete failure mode and acceptance criteria for the per-project/folder case:

When a project contains more threads than the sidebar initially renders, a thread with a currently running turn can remain hidden behind Show more. The user then has to expand the list repeatedly just to find and monitor work that is already in progress.

A global Active tasks section would help, but active threads should also be prioritized inside their own project/folder so the project context remains obvious.

Suggested acceptance criteria:

As soon as a turn starts running, its thread appears at the top of its project/folder, before paginated historical threads.
If two or three threads are running in the same project, show all of them in positions 1–N with a deterministic order (for example, most recent activity first).
Running threads must be selected before normal sidebar pagination and must never be hidden behind Show more.
Waiting-for-approval or waiting-for-input threads should remain visible at the top with a clear status, because they require user attention.
When a turn reaches a terminal state, the thread leaves the active group and returns to the user's normal sorting mode.
Active threads should not consume the ordinary first-page history quota; otherwise surfacing several active tasks would simply hide more normal history.

The key UX principle is: work that is currently running or needs attention should be easier to find than completed history.

everyai-com · 15 days ago

I explored this from the app-server side and built a focused local proof of concept for the pagination failure mode described here.

Proposed foundation:

Add an experimental thread/activity/list method that is independent of normal thread/list history pagination.
Return loaded threads whose canonical runtime status is active (including waitingOnApproval / waitingOnUserInput) or systemError, plus threads whose durable goal is blocked, usageLimited, or budgetLimited.
Reuse the existing Thread, ThreadStatus, active flags, and optional ThreadGoal projections rather than creating a second task record.
Cursor-paginate this activity projection separately, so active work never consumes the ordinary history quota or falls behind Show more.
Let Desktop hydrate from this method and stay current through the existing thread/status/changed, thread/goal/updated, and thread/goal/cleared notifications.

The proof includes generated experimental protocol schemas, app-server documentation, classifier unit coverage, and a public JSON-RPC integration test covering inactive-thread exclusion plus multi-page active results. The full protocol suite passes (286 tests), the focused classifier tests pass, and the end-to-end app-server test passes.

UI concept for the Active / Needs you / Board surfaces: https://superdesign.dev/teams/9a4ed826-fbd2-4bb1-927b-74f82465e80e/projects/e12c5988-d83a-4ea0-96c4-784bda3fa0c6?node=draft-variant-bd518bf9-5798-4287-bd1e-1fb3700cd1ae

Would the maintainers be open to this experimental app-server API as the backend foundation? If this direction aligns with the intended Desktop architecture, I would appreciate an invitation to submit the focused backend/protocol PR under the repository contribution policy. The Desktop frontend is not in this repository, so I would keep that follow-up explicitly separate.

EIradINO · 15 days ago

I’m seeing the same usability issue in Codex Desktop on macOS. When a project contains many tasks, a currently running task can remain far below the visible area at its normal list position, so it is easy to lose track of active work. Manual pinning is a workaround, but it requires managing pins before and after each run. Automatically keeping running and waiting-for-input tasks in a persistent top section would solve this cleanly.