Skip to content

[Bug]: Desktop sidebar looks idle while watch_pull_request reports watching: true #15924

Open
Open
[Bug]: Desktop sidebar looks idle while watch_pull_request reports watching: true#15924
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@Runiir
Runiir
opened on Oct 5, 2026

Before submitting

  • I searched existing issues and did not find an exact duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web (desktop sidebar status for app-owned PR watches)

What happened

A Codex thread was watching an open GitHub PR through T3's watch_pull_request tool. The assistant said T3 was watching and later verified watching: true, but the thread's row at the top left of the desktop app had no persistent watching/waiting marker or label.

The user-supplied screenshot shows the selected thread with its green PR #147 badge and a relative timestamp ("now"), while the conversation says the watcher is active. Another thread visibly shows "Working", so the concern is specifically the resting watched thread's status.

Steps to reproduce

This sequence was observed in a real session on the build below; a clean isolated reproduction has not been run.

  1. Open a Codex thread in a GitHub-backed project in T3 Code desktop.
  2. Link an open PR and call watch_pull_request for it. Confirm the returned watching value is true.
  3. End the agent turn while PR checks/review are still pending.
  4. Inspect the thread row in the left sidebar.
  5. Ask the agent to verify the watch with list_thread_pull_requests, then let that turn finish too.

Expected behavior

While an open PR is actively watched, the desktop thread row should visibly communicate that state, for example with a watching/waiting indicator. It should remain visible between agent turns so the user can tell the thread is waiting for PR updates.

Actual behavior

The sidebar row looks like an ordinary completed/idle thread, even after the agent verifies that the watch is still active. The PR badge is present, but it does not communicate that T3 will wake the agent on updates.

The watcher itself did deliver notifications and resume the thread. This report concerns the missing persistent UI status; the evidence does not show that watching stopped.

Impact

Minor bug or occasional failure. The user cannot tell whether monitoring is still active without asking the agent to inspect the watch state.

Version or commit

  • Installed desktop build: 0.0.46-nightly.20261004.2648.
  • Update channel: nightly.
  • Release target commit: 5a96895a85b43c838da6c89cf21068b99c003d5a.
  • Version was read from the running AppImage's resources/app.asar/package.json.

Environment

  • T3 Code desktop AppImage, Linux x86_64.
  • Ubuntu 26.04.1 LTS, kernel 7.0.0-34-generic.
  • GNOME desktop, Wayland session.
  • Electron 44.4.2, Chromium 152.0.7977.130, bundled Node.js 24.21.0.
  • Provider: Codex; model gpt-6.1-sol; xhigh reasoning; full-access mode.
  • Installed Codex CLI: 0.160.0.
  • GitHub CLI: 2.101.0.
  • Observation date: 2026-10-05.

Evidence

These are actual tool results and timeline entries from the original thread, inspected read-only. Unrelated repository details are omitted.

At 05:42:29.618 UTC, watch_pull_request completed:

{
  "number": 147,
  "watching": true,
  "wasWatching": false
}

The foreground run then completed at 05:42:38.584 UTC.

At 05:43:00.611 UTC, T3 delivered the notification #147: new comments and started another run.

At 05:44:23.609 UTC, after the user asked whether watching had stopped, list_thread_pull_requests returned:

{
  "pullRequests": [
    {
      "number": 147,
      "source": "agent",
      "watching": true,
      "state": "open",
      "isDraft": false
    }
  ]
}

That verification run completed at 05:44:32.490 UTC. The screenshot supplied by the user shows the assistant's confirmation and the sidebar without a watching/waiting marker.

At 05:47:04.753 UTC, T3 delivered another #147: new comments notification and resumed the same thread. This corroborates that the watch was functioning.

Source investigation

At the installed release's commit, resolveSidebarThreadStatus accepts only hasPendingApprovals, hasPendingUserInput, and runtime. It maps an idle runtime to waiting, but otherwise falls through to ready after the active/error cases. It does not directly consider a linked PR's watch state.

This suggests a gap between app-owned PR watches and sidebar status derivation. It is source-based inference, not a verified fix.

Related issues

Workaround

Ask the agent to call list_thread_pull_requests and inspect watching. No UI workaround has been verified.

Filed at the user's request by Codex (gpt-6.1-sol, xhigh) running in T3 Code.

Activity

  1. juliusmarminge commented on Oct 5, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 5, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks @Runiir for such a careful report. The tool results with timestamps and the pointer to resolveSidebarThreadStatus made this quick to trace.

    What I found

    • watch_pull_request stores the watch on the pull request link (ThreadPullRequestLink.watch), and the watch itself is working, as your later #147: new comments wakes show.
    • Once the turn ends, the thread row's label comes only from resolveSidebarThreadStatus, which checks pending approvals, pending input, and runtime status. Runtime is parked at idle (the grey Waiting label) only for provider background work that will wake the agent, such as subagents, provider monitors, and unnamed background tasks. An app-owned pull request watch isn't part of that set, so a finished turn resolves to ready and the row shows no status label. The green #147 badge is the open-pull-request glyph, not a watch indicator.
    • The same status logic drives the mobile thread list (resolveThreadListV2Status), and the Working-section fold (isThreadWorking) uses the same runtime, so a watched thread looks finished there too until a wake starts a turn.
    • Today the watch state is visible on the pull request itself, from feat(server): agents can watch a PR and get woken when checks, reviews, or conflicts need them #15057: the eye icon on the row in the Linked pull requests panel on web and desktop, and " · Watching" in the mobile Git overview subtitle. It isn't surfaced on the thread row between turns.
    • This is still the case on main after 0.0.46-nightly.20261004 (5a96895). [Bug]: iOS does not show Monitoring status displayed on desktop and web #10372 (provider Monitoring label on iOS) and [Bug]: Creating a thread from a pull request does not link the pull request to the thread #15721 (PR failing to link) are different cases.

    Likely fix area

    resolveSidebarThreadStatus in apps/web/src/components/Sidebar.logic.ts and its mobile counterpart resolveThreadListV2Status. Options include feeding active pull request watches into status derivation so a watched idle thread reads as waiting, or adding a separate watch marker on the thread row, while keeping the Working-section fold consistent with whichever direction is chosen.

    A maintainer will decide on the fix direction.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 5, 2026

  3. bman654 commented on Oct 5, 2026

    @bman654
    bman654
    on Oct 5, 2026

    Came here to post the same issue. It's even worse than described. Status of the thread is marked as Done. 3 of 4 PRs are not yet merged. Agent is actively watching 1 PR.

    Image Image

    Today the watch state is visible on the pull request itself, from #15057: the eye icon on the row in the Linked pull requests panel on web and desktop, and " · Watching" in the mobile Git overview subtitle. It isn't surfaced on the thread row between turns.

    I cannot find any such eye icon:

    Image Image Image

    In addition to some sort of indicator on the left thread panel, what I'd really like to see:

    • Add a new "Monitoring" section (like we have Working and Settled)
    • be able to do is right-click on a Thread that has a PR Watch, or even some other background task (like a custom Monitor script) and say "Move to Monitoring". The thread will move to monitoring and will stay there until the monitor/watch stops (hopefully the agent remembers to unwatch the PR when it is done babysitting, or the PR auto-unwatches when merge status changes).
    • Don't automatically move threads to monitor section because often the monitor is a secondary activity while you are actively doing other primary work with the thread.

  4. bman654 commented on Oct 5, 2026

    @bman654
    bman654
    on Oct 5, 2026

    oh my t3code version: 0.0.46-nightly.20261004.2657 (efecd3cf8bce)

  5. moritzwesemann commented on Oct 5, 2026

    @moritzwesemann
    moritzwesemann
    on Oct 5, 2026

    Also confirmed on macOS arm64, with 0.0.46-nightly.20261005.2689 (bundled commit 3e6b45028cee), orchestrator V2, and a Claude thread.

    The user reports that the chat on their phone indicates background work, but after navigating elsewhere the thread appears finished / ready for their input. This makes it hard to trust the Working section when using T3's internal watcher.

    Fresh read-only inspection of an existing thread returned these relevant fields (unrelated identifiers omitted):

    // list_thread_pull_requests: the watched PR
{"state":"open","watching":true,"isDraft":false}

// t3_thread_read: the owning thread
{"status":"completed","activeRunId":null,"pendingRequestCount":0}

    The active provider's background-task roster contained only a command, with no monitor. This corroborates the distinction in the triage reply: the app-owned PR watch is stored on the PR link, independently of the provider background-work roster.

    At this build's commit, background-work derivation reads the provider roster and active turn items, without considering PR-link watches. Shell runtime presentation parks the thread in a waiting state only when that background work holds completion; command-only work does not. The Working-section predicate then sees a completed runtime and excludes the thread.

    Expected: an active T3-owned watch should remain visible consistently on thread rows and in section placement between turns, without suggesting that user input is needed when no request is pending.

    Verification limits: the phone symptom is user-reported; I verified the live watch/run state and installed code, but did not capture the phone UI or run a clean isolated reproduction. No code or configuration changes were made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions