Visible unarchived threads are absent from the app list until opened by direct link

[pixexid]

Summary

A visible, unarchived tenant lane thread can be absent from the BB app's thread list until the operator opens that exact thread through a direct thread link. After the direct open, the thread appears in the list.

Native thread identity and native list reads are already correct, so the observed shape is an app list bootstrap/filter/subscription invalidation defect rather than a visibility mutation.

BB CLI: 0.39.0.

Observed evidence

Two independently reported examples in one project:

• thr_8n32y4ujbs: idle, visibility=visible, archivedAt=null, deletedAt=null
• thr_s5843imarf: active, visibility=visible, archivedAt=null, deletedAt=null

Both exact records are returned by:

bb thread show <thread-id> --json
bb thread list --project proj_7iaaqem8z3 --include-hidden --json

The complete project list contained 30 threads at verification time and included both targets. This is not a large-list boundary.

Operator observation:

1. Open the project in the BB app.
2. Inspect its thread list; the visible lane thread is absent.
3. Open the exact thread through a direct bb://thread/<id> link.
4. Return to the project thread list; the same thread now appears.

All 29 tenant records present during the original audit had correct native visibility flags. No native visibility repair occurred between absence and appearance.

Expected

Every visible, unarchived, undeleted thread returned by the project's native thread-list authority should be represented by the app list's documented filtering/progressive-disclosure state without requiring the thread to be opened first.

If the list intentionally paginates or progressively discloses items, the UI should expose that state and permit discovery; opening an exact thread must not be the cache-insertion mechanism.

Suggested investigation

• Compare initial project/sidebar bootstrap rows with the cache after opening an exact thread.
• Check project-id filtering, recent-thread pagination, and subscription invalidation for plugin-originated managed-worktree lanes.
• Verify whether direct open inserts the fetched detail record into a list cache that was incomplete or filtered at bootstrap.
• Cover both active and idle visible lanes and a project with roughly 30 threads.

Acceptance

• A visible active or idle thread returned by the native project list is discoverable before direct open.
• Direct opening a thread does not change whether it qualifies for list membership.
• Pagination/progressive disclosure remains explicit and can reveal every qualifying thread.
• A regression test exercises initial list bootstrap followed by direct detail open and proves membership is unchanged.

⚠ Agent-generated: An AI agent independently verified the native records and CLI list membership. The before/after app observation was reported by the operator and tenant director; please verify the UI reproduction.