Projects Sort By Last updated only sorts tasks within project groups, not projects

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30778

Powered by Codex Action

Additional confirmation from a current Codex desktop installation:

• Codex app version: 26.707.31123 (5042)
• The selected value is persisted correctly as updated_at, so the menu action itself is not being dropped.
• Inspecting the shipped renderer bundle shows that the selected sort mode is passed to the task-sorting function for threads inside each project.
• Project groups are constructed separately using the persisted project-order list before that task sorting occurs.

So in Projects mode, “Last updated” changes task ordering within each project but does not change the order of the project groups themselves. When projects are collapsed—or contain only one visible task—the control appears to be a complete no-op.

This looks like an implementation/UX mismatch rather than corrupted local state. Possible fixes:

1. Apply the selected sort mode to project groups as well, using each project’s latest/created task timestamp; or
2. Relabel the control to “Sort tasks by” if it is intentionally scoped only to tasks within projects.

Thanks for digging into this. That matches the user-visible behavior I was seeing.

From a UX standpoint, I think option 1 is the expected behavior: in Projects mode, Sort By -> Last updated should sort the project groups themselves by the latest relevant timestamp among their visible/contained tasks, not only sort tasks inside each already-ordered group.

Suggested acceptance criteria:

• In Projects mode, selecting Last updated reorders project groups by each project's latest task/thread activity timestamp.
• Projects with one visible task or collapsed task lists still visibly move when their latest activity differs.
• Task ordering within each project may continue to use the selected sort mode, but group ordering should not remain pinned to persisted project-order when a global sort is selected.
• If product intent is actually task-only sorting, then the control should be relabeled to Sort tasks by to avoid implying project group sorting.

My preference is the first path because the control is exposed at the Projects-view level, so users reasonably expect it to affect project groups. Otherwise it reads as a no-op in the common collapsed/one-task case.

One important clarification: this appears to be a regression, not just a long-standing UX mismatch.

The reporter observed that Projects -> Sort By -> Last updated previously did reorder project groups by latest activity. That behavior was working before and appears to have stopped today.

So the expected behavior is not only inferred from the control label; it is also the behavior users had already been relying on.

Confirmed on the newly merged ChatGPT/Codex desktop app, and I was able to isolate the overriding state.

Environment

• macOS
• ChatGPT desktop 26.707.31428 (5059)
• Bundle identifier: com.openai.codex
• Reproduced on 2026-07-09, immediately after the ChatGPT/Codex desktop merge

Reproduction

1. Use Projects → Organize: By project.
2. Select Sort by: Last updated.
3. Update/create the newest task inside project B.
4. Project B remains below older project A.
5. Quit and reopen the app; the fixed project order remains.

The selected sort mode itself persists as updated_at, so this is not the same failure as #30778, where the selection reverts to manual order.

Root-cause evidence

Inspecting the shipped renderer shows this sequence:

1. Project groups compute a recency value from projectUpdatedAt and the maximum contained task recencyAt.
2. The groups are sorted descending by that value.
3. The result is then passed through the persisted project-order list.
4. Because project-order contains every active project ID, that stored order overrides the recency sort completely.

The selected Last updated mode is also passed to the task sorter, which explains why tasks can reorder within a project while the project headings remain fixed.

As a diagnostic proof, I replaced project-order through the app's own global-state API with one non-matching sentinel and invalidated the corresponding query cache. The project headings immediately reordered by their latest contained task activity, with the newest project moving to the top. That confirms the persisted manual project order is the overriding layer.

Clearing project-order to an empty array is not a durable workaround because the app repopulates it with all active project IDs on restart.

This is a regression from the prior Codex desktop behavior, where Last updated also reordered the project groups. A regression test should cover a populated persisted project-order, then switch to updated_at and assert that project B moves above project A when B contains the newest task.

Confirming this as a cross-platform regression in the newly merged ChatGPT/Codex desktop experience. This comment concerns the post-merge app; the older issues below are included only as regression history.

Additional environments

• Windows: installed Codex package OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
• macOS: reproduced on a separate machine with a separate account
• The two accounts also use different account/workspace configurations, which makes a machine-specific cache problem or a single-account rollout variant unlikely.

Observed behavior

The Projects menu now offers three ordering modes: Priority, Last updated, and Manual order. Switching among all three produces no visible change in the project-group order. The list remained in the same unintuitive order immediately after the product merge/update.

On macOS, I also created new chats/tasks inside a project that was lower in the list. Even with Last updated selected, activity in that project did not move it toward the top.

This matches the implementation evidence already documented in this issue: a populated persisted project-order appears to override the selected global sort mode. It also connects directly to two older reports:

• #23462, my May report about the project sidebar becoming scrambled and the ordering preference changing after authentication transitions
• #22487, “Recent projects no longer move to the top,” which was closed as completed on June 15

The recurrence after the ChatGPT/Codex merge strongly suggests a regression rather than isolated local state. It is concerning that a project-navigation problem that was previously reported—and, in the closely related case, apparently fixed—could ship again in a major product merge.

User impact

For accounts with many projects, this makes recent work difficult to find and forces repeated scrolling through an order that the controls cannot change. It is also poor onboarding: a new user is presented with three explicit sort choices, but every choice appears broken.

Please treat this as a release regression and add end-to-end coverage for the actual project headings, not only the tasks inside each heading. At minimum, a regression test should:

1. Start with several projects and a populated persisted manual project-order.
2. Select each of Priority, Last updated, and Manual order, and assert the expected project-group order.
3. Create or update a task in a lower project and assert that Last updated moves that project to the top.
4. Verify the selected behavior after restart and sign-out/sign-in.
5. Exercise the upgrade path on both Windows and macOS.

This should be caught before rollout because the failure is visible through ordinary use of the primary Projects navigation.

@etraut-openai, could you please route this post-merge regression to the current Projects/sidebar owner? You publicly triaged #22487 as an app regression in May; that report was later closed as fixed, but the same core behavior—recently active projects not moving to the top—has returned in the merged 26.707 app, now alongside three ordering controls that appear ineffective.

The cross-platform evidence and implementation analysis above make this more than a preference-persistence problem. A populated manual project-order overrides Last updated, so ordinary activity cannot move a project to the top. This is visible on both Windows and macOS immediately after the merge and needs an actual project-group sorting regression test.

What I found is that some projects actually can change to the top. Incidentally, those were the projects already being in the first one or two positions, whereas other projects much further down did not go to the top. And even though one selected sorting by latest update. The manual sorting is working and I can move entries around, which is maybe a temporary fix for now to just manually keep track of this, but this is still not really good because important things can get buried under a lot of other old projects.

@claell or quit + run a script + open
https://github.com/openai/codex/issues/32166#issuecomment-4936705327

Crazy that this regression already happen like 5 times so far in Codex app 😂

Crazier that this still hasn’t been fixed. The core problem this app is designed to solve cannot be addressed while this bug exists.

Still reproducible on ChatGPT/Codex for macOS 26.707.41301 (build 5103).

With Projects → By project → Last updated, project headings continue to follow the persisted project-order, while conversations inside each project sort correctly by recency. “In one list” produces the correct chronological order.

I submitted in-app feedback with session and browser logs attached.
Feedback ID: 019f47fd-477a-7703-93ea-34e2b7fd45a3

I have the same problem!

Same issue. please fix. slows down workflow immensely

I found a specific reproducible pattern that may help narrow down the cause.

<img width="384" height="474" alt="Image" src="https://github.com/user-attachments/assets/590ddb2d-3c6b-42e4-a8b8-bb201889c849" />

With Organize → By project and Sort by → Last updated, projects whose names end with -1 and -2 do not move to the top after activity inside them.

Steps:

1. Create or use a project ending in -1, such as example-1.
2. Select By project and Last updated.
3. Create or update a task inside that project.
4. Observe that the project remains in its previous position.

Expected: The project moves to the top because it contains the most recently updated task.

Still have the same issue in the latest version macOS 26.707.72221

Still reproducible on macOS with ChatGPT/Codex 26.707.72221 (build 5307).

I also tested the temporary script from #32166 after fully quitting the ChatGPT app and its app-server process.

Before reopening, the state file was correct:

project-order was sorted using the latest recency_at_ms from state_5.sqlite.

projectSortMode was set to updated_at.

Immediately after reopening the app, it restored the previous manual project-order and changed projectSortMode back to priority, while the UI continued to show Last updated as selected.

Therefore, the script workaround is not durable on this build. In one list is the only mode that currently provides correct chronological ordering; By project → Last updated remains broken.

Adding another confirmation: this is still reproducible on macOS with ChatGPT/Codex 26.707.72221 (build 5307).

With Projects → By project → Last updated, new activity inside a lower project does not move that project to the top. Conversations may sort within each project, but the project groups remain effectively pinned. With many projects, this makes active work difficult to find and adds significant friction to the core workflow.

Please prioritize this regression and ensure that Last updated sorts the project groups themselves by their latest contained activity, not only the conversations inside each group.

Same issue. Windows 11. This broken feature has significantly reduced my productivity.

Still reproducible for us on Codex desktop 149.0.7827.197 on macOS 26.5.1 (build 25F80), Apple Silicon (arm64).

In Projects view, selecting Sort by → Last updated does not move recently active projects to the top; the project order remains unchanged. This makes it difficult to find current work in a larger project list.

Confirming that this is still impacting daily use and would appreciate prioritization.

Still reproducible on the newer merged ChatGPT/Codex desktop app:

• App version: 26.715.21425 (build 5488)
• macOS: 26.5.1 (build 25F80)
• Platform: Darwin 25.5.0 arm64 arm

With Projects → By project → Last updated, pinned projects remain pinned (which is expected), but all unpinned top-level project groups continue to follow the saved static order instead of the latest activity of their contained tasks/threads.

I verified this by comparing the projects' latest thread activity timestamps: less-recent projects remained above more-recent projects, and restarting the app did not correct the order. A one-time offline recomputation of the saved project order immediately changed the visible sidebar order, confirming that the thread recency data exists but is not being applied dynamically to top-level project groups.

Expected behavior: keep pinned projects first, then sort all unpinned project groups in descending order by the latest activity of their contained task/thread.

Verified on Codex App 26.715.21425 on macOS 26.5.2 arm64.

I reproduced this with a project that was not first in the sidebar:

1. Send a new message in a thread under that project.
2. The thread's activity timestamp (recency_at_ms in the local thread database) updates correctly.
3. The persisted project-level project-order remains unchanged, so the project does not move to the top.
4. Updating project-order through Codex's own set-global-state request path causes the sidebar to reorder immediately.

This suggests that the task/thread recency path is working, but the app is not recomputing the project-level ordering when activity changes. The behavior also persists across an ordinary app restart.

I initially noticed it after changing the configured model provider, but the provider does not appear to be causal: the sidebar behavior is controlled by the persisted project ordering, while message routing and thread activity continue to work normally.

As an external validation, continuously recomputing each project's maximum thread recency and updating project-order restored the expected behavior; a deliberately incorrect order was corrected in about 239 ms. No DOM reordering was required.

Confirming this regression is still reproducible on a newer unified ChatGPT/Codex desktop build:

• App version: 26.715.52143 (build 5591)
• Platform: macOS, Apple Silicon
• Sidebar: Projects → By project

Reproduction

1. Select Sort by → Last updated.
2. Send a new message or create new activity inside a project that is lower in the sidebar.
3. The chat/thread activity updates, but the top-level project folder does not move upward.
4. Switching between Priority and Last updated does not change the project-folder order.
5. Switching to In one list does show the chats in the expected chronological order.

Read-only local verification

The selected sort preference is persisted correctly, so the menu selection is not being lost. However, the visible top-level project order exactly follows the persisted static project-order list. A project with newer contained activity remains below a project with older activity.

This worked in the earlier Codex desktop experience, where new activity inside a project moved that project toward the top. The regression appeared after moving to the unified ChatGPT/Codex desktop app.

Expected behavior: with Last updated, keep pinned projects first and dynamically order all unpinned top-level project groups by the latest activity of their contained chats/tasks.

i hope they can fix it as soon as possiable

This issue is still reproducible in version 26.715.61943 (Windows).

Still reproducible on a newer macOS build:

• ChatGPT/Codex: 26.715.61943 (build 5628)
• macOS: 27.0
• Architecture: arm64

With Projects → By project → Last updated, sending a new message in a lower project does not move that top-level project group upward. The project groups remain in their persisted static order.

This continues to affect daily navigation across multiple active projects. Please prioritize this regression.

It's been so long, and they still haven't fixed a simple but very irritating issue. Maybe you can only get them to fix it by posting about it on X.

@owenlin0 @etraut-openai @jif-oai @pakrym-oai

Sorry if this isn't the ideal way to get attention on the issue, but I wanted to escalate this because the impact is very real.

Since the ChatGPT/Codex merger, Projects → Sort by → Last updated appears to be broken for many users. It used to reorder project groups correctly, but now the project list often stays pinned to project-order even when activity clearly changes. For people managing multiple projects at once, this is a major workflow breaker.

This is especially frustrating because marketing updates (email/X.com) keep promoting sidebar improvements, while in day-to-day use this still feels like a clearly broken regression. I keep seeing this repeated by community members, and it's actively harming productivity.

The community has also validated and patched behavior in the Linux fork here:
https://github.com/ilysenko/codex-desktop-linux/pull/1059/changes

Please prioritize a fix for this regression. For multi-project users, this issue is no longer a small nuisance - it's become a serious, productivity-impacting problem.

Confirmed on Windows in Codex 26.715.9757.0 (x64).

Current-build reproduction

With Projects → By project → Last updated selected, sending a new message in a lower project updates that thread's recency, but the top-level project group does not move above older projects. The conversation rows can change order within a project while the project headings remain fixed.

Read-only root-cause verification

Inspection of the shipped renderer and local state confirms the following sequence:

1. Each project group receives a recency value computed from projectUpdatedAt and the maximum recencyAt of its contained threads.
2. Project groups are correctly sorted descending by that recency.
3. The recency-sorted result is then unconditionally passed through the persisted PROJECT_ORDER / project-order list.
4. When the persisted list contains all active project IDs, it completely overrides the recency ordering.
5. The selected projectSortMode: "updated_at" is applied later to thread keys inside each project, not to the project-group list.

This explains why Last updated appears to work for task rows but not for the project headings. It also explains why clearing project-order temporarily restores the desired behavior and why the bug returns when the app repopulates that state.

Suggested minimal fix

• Pass the selected projectSortMode into the project-group sorter.
• For updated_at, return the already computed recency-sorted groups without reapplying the persisted project order.
• Preserve the current behavior for other modes until their project-level semantics are handled explicitly; in particular, manual should continue to use the persisted order.
• Keep pinned-project handling separate so pinned groups remain ahead of the dynamically sorted unpinned groups.

Conceptually:

const recencySortedGroups = sortProjectGroupsByLatestActivity(groups, items);

return projectSortMode === "updated_at"
  ? recencySortedGroups
  : applyPersistedProjectOrder(recencySortedGroups, projectOrder);

Regression coverage

Start with projects A and B plus a populated persisted order [A, B]. Give B the newest contained-thread activity, switch to updated_at, and assert that the visible project order becomes [B, A]. The test should also verify that manual still produces [A, B] and that pinned projects remain unaffected.

The equivalent behavior has already been implemented and tested as a bundle-level patch in ilysenko/codex-desktop-linux#1059. The desktop renderer/sidebar source is not present in the public openai/codex checkout, so an upstream source PR cannot currently be prepared from the public repository.

still not fixed! I submitted feedback: 019f88bd-9186-77e2-a159-8fd1f7fde853

Please fix soon @tibo-openai

Please fix this!

Still reproducible on a newer macOS unified ChatGPT/Codex desktop build:

• App: ChatGPT.app / bundle com.openai.codex
• Version: 26.721.41059
• Build: 5848
• Platform: macOS
• Sidebar mode: Projects / By project / Last updated

Observed behavior matches this issue: recent thread activity updates correctly, but the top-level project group order does not move accordingly. Read-only local checks show valid thread updated_at / recency data in ~/.codex/state_5.sqlite; the stale behavior appears limited to Desktop project-group/sidebar ordering.

I also posted the fuller local confirmation and related evidence on #33077: https://github.com/openai/codex/issues/33077#issuecomment-5080635076

The affected user has also submitted in-app /feedback with logs from the same installation.

Confirmed on Windows (Microsoft Windows NT 10.0.26200.0 x64) with Codex App 26.721.4979.0.

With Projects → By project → Last updated selected, the preference remained updated_at, but project groups continued following the stale persisted project-order.

After fully exiting Codex, backing up the global state, and removing only the top-level project-order, recent-first project-group sorting worked after restart in this test. This supports the existing diagnosis that persisted manual ordering is reapplied after recency sorting.

Important clarification: merely opening an older task did not update project-level recency, suggesting that task access and project update activity are separate signals.

Suggested upstream fix: apply persisted project-order only for Manual order. For updated_at, retain the already computed project-recency order while keeping pinned projects separate.

Follow-up to my previous Windows confirmation with a newly isolated recurrence path on Codex App 26.721.4979.0.

Deterministic recurrence after the one-time workaround

1. Fully quit Codex, back up the global state, clear only the top-level project-order, and keep projectSortMode: "updated_at".
2. Restart Codex. Existing unpinned project groups initially follow latest activity again.
3. Create new local projects.
4. Each newly created project appears at the bottom of the project list instead of the top.

After creating three projects, the live state still had projectSortMode: "updated_at", but project-order had been regenerated with exactly those three new project IDs. The selected preference was therefore not lost.

Shipped-bundle evidence for the recurrence

The current Windows bundle contains both sides of the failure:

• Local project creation calls an order update equivalent to:

set(PROJECT_ORDER, [newProjectId, ...existingOrderWithoutNewProject]);

• Project groups are first sorted by computed recency, but the result is then unconditionally passed through the persisted project-order helper.
• That helper constructs the effective order as:

[...projectIdsNotPresentInProjectOrder, ...persistedProjectOrder]

So after the workaround clears project-order, all existing projects are in the first (unlisted) partition. Creating a project immediately puts only that new ID into the persisted partition, which is appended after all unlisted projects. This deterministically sends the newest project to the bottom. Additional new projects are ordered within that bottom partition, but remain below all older unlisted projects.

This explains why clearing project-order can appear to fix the bug once, yet creating another project makes it recur without any restart or preference change.

Minimal upstream fix

The final project-group projection should not apply persisted project-order when projectSortMode === "updated_at":

const recencySortedGroups = sortProjectGroupsByLatestActivity(groups, items);
return projectSortMode === "manual"
  ? applyPersistedProjectOrder(recencySortedGroups, projectOrder)
  : recencySortedGroups;

Pinned projects can remain handled separately as they are now.

Regression coverage

A focused regression test should:

1. Start with existing projects A and B and project-order: [].
2. Select updated_at and verify the project with newest contained activity is first.
3. Create project C and assert C appears at the top, not after A and B.
4. Verify project creation does not make persisted manual ordering override updated_at.
5. Switch to manual and verify persisted order still applies there.

The offline state-clearing script should be treated only as a one-time recovery, not a durable fix, because project creation itself repopulates the overriding state.

补充一份当前 macOS 版本的匿名化确认。

环境

• ChatGPT / Codex 桌面版：26.721.41059
• Build：5848
• Bundle：com.openai.codex
• 平台：macOS
• 侧栏设置：按项目显示 + 按更新时间排序

本机证据

• projectSortMode 与任务排序键均正确保存为 updated_at，所以不是选项未持久化的问题。
• 匿名化统计中共有 18 个活跃本地项目，其中 17 个项目的“创建顺序排名”和“项目内最新任务 recency 排名”不同；因此这两种排序在本机具有明确可观察差异。
• 实际侧栏仍遵循持久化的项目顺序，而项目内部任务会按更新时间变化。
• 当前合并版桌面状态同时存在两层项目顺序：顶层 project-order，以及渲染侧的 unified-sidebar-project-order-v1。两者均有已保存项目项，会覆盖已经计算出的项目 recency 顺序。

临时规避验证

在完全退出 App 并备份全局状态后，仅清空上述两份项目顺序，再重新启动：

• 两个顺序数组保持为空；
• projectSortMode 仍为 updated_at；
• 项目定义、置顶项目和统一置顶顺序均保持不变；
• 本地任务数据库 PRAGMA quick_check 返回 ok；
• 当前活跃项目按其任务最大 recency_at_ms 计算为第 1。

这进一步支持现有根因判断：持久化项目顺序应只在 manual 模式应用；updated_at 模式应直接保留按项目内最大任务 recency 得到的项目组顺序，并继续单独处理置顶项目。

该状态清理只能作为临时恢复措施；新建项目或手动调整项目后，顺序状态可能再次生成，因此仍需要客户端代码修复。

感谢这份非常完整的 macOS 匿名化验证。

你发现的 unified-sidebar-project-order-v1 很关键：它进一步支持了我们此前关于持久化固定顺序覆盖 recency 排序的根因判断，同时也说明 macOS 当前版本存在一个 Windows 证据中尚未覆盖的第二层渲染顺序状态。

我们此前已将 Windows 上验证过的恢复流程整理为一个不可变的 Noosphere Skill：

codex-project-recency-sort-recovery@1.0.0

当前版本是 maintainer-validated，SHA-256 为 4d91e0d4dab3fe9cf68ebaf3ac75c1899327918a5dc4a1d7eded6922bf5cb8fd。

不过需要明确：1.0.0 故意限定为 Windows，并且只处理顶层 project-order，所以不应该直接在 macOS 上照搬。你的结果说明，真正的 macOS 支持应当进入新的不可变版本，而不是修改或重新解释现有 1.0.0。

如果你愿意，我想邀请你共同验证这个 Skill 的下一版本：

1. 先审阅 1.0.0 中的触发条件、根因和安全边界；
2. 我们根据你的证据准备同时处理两层项目顺序的 macOS / cross-platform 候选版本；
3. 保留项目定义、置顶项目、统一置顶顺序，并继续要求完全退出 App、先备份、验证 JSON 和数据库；
4. 只在问题自然再次出现时测试，不需要为了验证而主动破坏当前正常状态；
5. 最终如实记录 success、partial 或 failure。

你当前的评论会被视为独立的技术复现证据，而不会被追溯描述成“已经使用了 Noosphere Skill”。

如果你愿意参与，我可以先给出一个最小、可审阅的 macOS 候选流程。

I can reproduce a related task-level ordering problem inside an expanded project group.

Environment

• Codex app: 26.727.51351 (build 6119)
• macOS: 27.0 (26A5388g)
• Architecture: Apple Silicon / arm64

Reproduction

1. Open an existing project group that already contains several completed tasks.
2. Start a new task in that project.
3. Start another task while the first new task is still active.
4. Observe the order inside the expanded project group.

Actual result

The newly created active tasks are inserted below the previously loaded completed-task snapshot instead of moving to the top. The two new tasks are ordered correctly relative to each other, but both remain below several older completed tasks.

Read-only local inspection shows the persisted timestamps and task catalog are correct: the newest active task has the newest creation/recency timestamp, and the app's thread-list API returns it ahead of the older tasks. This points to a sidebar render/cache merge or re-sort problem rather than incorrect persisted timestamps.

The visible order can recover after the active tasks finish and the project group/app is refreshed.

Expected result

When sorting by last updated/recency, a newly created or newly active task should immediately appear at the top of its project group without requiring a refresh.

I have a screenshot of the stale ordering if maintainers need it, but I have omitted private project and task names from this public comment.

Thank you — this is a distinct task-level failure, and the timestamp/API observation narrows it substantially.

The existing evidence now points to two separate ordering layers:

1. At the project-group level, persisted manual project order can override the selected recency order.
2. Inside an expanded group, newly active tasks can be merged below a retained completed-task snapshot even though their canonical recency and the thread-list API already place them first.

So this second case looks like a sidebar snapshot/cache merge that is missing a final recency sort, rather than the persisted timestamp or server/task catalog being wrong. The existing Windows-only recovery guidance for top-level project-order does not apply to this macOS task-level case.

A focused client regression should begin with an expanded group containing completed tasks, create two active tasks without collapsing or refreshing, and assert the rendered order immediately becomes newest-first. It should also verify the same order after task completion and a group/app refresh; checking only the thread-list API would miss this failure.

If you would like your redacted reproduction to become a reusable public Experience record, you can submit it voluntarily through the Noosphere Experience form. It now validates identity, privacy, safety, and declared workflow evidence automatically, then records a passing descriptive case without treating it as a callable Skill or an independent reproduction. Please do not include private project/task names; the screenshot is optional.

Please codex prioritize this bug, it's really annoying and affecting productivity.

Still reproducible on macOS with ChatGPT/Codex 26.803.41515 (build 6321).

Configuration:

• Projects → By project
• Sort by → Last updated
• projectSortMode is correctly persisted as updated_at

Redacted local-state inspection shows two persisted project-order layers:

• top-level project-order: 40 project IDs
• electron-persisted-atom-state.unified-sidebar-project-order-v1: 40 project IDs

The visible top-level project groups remain in a static order instead of moving according to their latest contained task activity.

On earlier builds, fully quitting the app and removing only the top-level project-order temporarily restored recent-first sorting. On the current build, that is no longer sufficient: the order is restored after restart, consistent with the second unified-sidebar-project-order-v1 layer repopulating it.

Expected behavior:

• updated_at should ignore both persisted manual-order arrays for unpinned project groups.
• Persisted project order should be applied only in manual mode.
• Pinned projects should remain handled separately.

This regression has persisted across repeated desktop updates and significantly disrupts navigation with around 40 active projects.

@etraut-openai @ambrosino-oai @noambrown @tibo-openai Is there any chance we can get attention to such annoying, potentially easy to fix regressions in Codex? Or are you just too covered with work and can't fix or triage such things right now?

Do you need more manpower for triaging or setting up proper systems? More devs for Codex?

Still the same. it's been a month since this bug appeared on the unified gpt app and still not fixed.

It's so incredibly annoying and bad for productivity

I traced this on macOS in Codex 26.810.52044 (build 6662). My state had 28 local projects but only 27 IDs in project-order. The project missing from that list was always placed first, even though it had not been used for months. The bundle code first sorts project groups by recency, then applies project-order, which overrides the result and prepends IDs missing from the saved list. After fully quitting Codex and clearing project-order in both ~/.codex/.codex-global-state.json and its .bak file, the sidebar returned to the correct recent-first order. A likely fix is to skip project-order for recency sorting, or only apply it in manual mode.

For users where Projects → Sort by → Last updated has no effect: a persisted project-order list overrides recency sorting.

Method:

1. Fully quit Codex Desktop.
2. Back up the global state file (%USERPROFILE%.codex.codex-global-state.json on Windows, ~/.codex/.codex-global-state.json on macOS).
3. Clear only the top-level project-order array in that file (leave projectSortMode set to "updated_at"), save, and restart.
4. Project groups now follow Last updated — until you manually reorder projects again, which repopulates the list.

Evidence: confirmed on Windows (Codex 26.721.4979.0) and on macOS; the global state file exists locally with the project-order key, and renderer analysis shows the persisted order is applied after the recency sort. Note: a separate task-level ordering layer inside expanded project groups may still be affected.

Independent community workaround; not an official OpenAI fix.

One additional bundle-level finding for macOS build 6744 (26.814.41957):

The renderer contains a function named Jnn that sorts project groups by their newest contained task. This function is active through a separate selector named pHs, which builds the recency-sorted project list used by the composer’s “Work in a project” command and other project pickers.

The active desktop-sidebar selector LS does not invoke Jnn. It reads projectSortMode, separates pinned and unpinned groups, and then passes the unpinned groups and persisted PROJECT_ORDER through von.

von is only a thin wrapper around sin:

function applyProjectOrder({ groups, projectOrder }) {
  return sortGroupsByPersistedOrder(groups, projectOrder);
}

sin reconciles the persisted order with the currently active projects, builds a project-ID rank map, and sorts the groups by that rank. Projects missing from the persisted array are placed first in their existing discovery/input order, followed by the persisted project IDs that still exist.

Equivalent unminified structure:

function sortGroupsByPersistedOrder(groups, projectOrder) {
  const activeProjectIds = new Set(
    groups.map(group => group.projectId)
  );

  const persistedProjectIds = (projectOrder ?? []).filter(
    projectId => activeProjectIds.has(projectId)
  );

  const persistedProjectIdSet = new Set(persistedProjectIds);

  const effectiveOrder = [
    ...groups
      .map(group => group.projectId)
      .filter(projectId => !persistedProjectIdSet.has(projectId)),
    ...persistedProjectIds,
  ];

  const rankByProjectId = new Map(
    effectiveOrder.map((projectId, index) => [projectId, index])
  );

  return [...groups].sort(
    (a, b) =>
      (rankByProjectId.get(a.projectId) ?? Number.MAX_SAFE_INTEGER) -
      (rankByProjectId.get(b.projectId) ?? Number.MAX_SAFE_INTEGER)
  );
}

Neither von nor sin checks projectSortMode or task timestamps. After applying that static group order, LS uses projectSortMode only when sorting the child chats inside each project.

This means the app already ships and uses the desired project-recency sorter, but the active sidebar path uses the persisted-order implementation instead. That points to a disconnected integration or regression during the sidebar refactor rather than a missing sorting implementation.

Build evidence:

• App: 26.814.41957 (build 6744)
• app.asar SHA-256: 881d21270e41ea50a6de7835a3dda3516a001354d034933bb4a97677f3e0c479
• Renderer: webview/assets/app-initial-BnNjcVmf.js
• Jnn definition: approximately byte 2,335,156
• sin definition: approximately byte 2,349,230
• Active LS selector: approximately byte 2,380,916
• The invocation of Jnn from pHs: approximately byte 10,022,368

The minified names and offsets are specific to this build.