Skip to content

[Bug]: Android sends a new Done notification every time a background agent or task wakes the thread, with Ongoing Agent Activity off #14831

Closed

Description

@Neonsy

Before submitting

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

Area

apps/mobile

Steps to reproduce

  1. Install the Android app 1.3.0 from Google Play, sign in to T3 Connect, and link a desktop environment
  2. In Settings → Notifications, keep Device Notifications on and turn Ongoing Agent Activity off
  3. In a Claude thread on desktop, ask the agent to start a background agent (run_in_background) that sends the main agent a few progress messages with SendMessage over a couple of minutes, and to end its turn without waiting
  4. Leave the phone locked or the app in the background while the background agent works

Expected behavior

One Done notification when the task as a whole finishes, or at least no more than one Done notification per thread while background work keeps waking it

Actual behavior

The phone shows a new Done notification each time a background agent message or a background task notification wakes the main agent. Each wake-up starts a short new turn, the turn completes, and the relay sends another completed alert. From the user's side it is one long task, but the thread's working timer keeps resetting and the phone keeps buzzing

In one real session the main agent was woken 55 times by something other than the user (29 task notifications and 26 messages from a background agent), and the phone received a Done notification for these wake-ups

A turn with foreground parallel subagents does not reproduce this. It produces a single Done notification because the main agent waits for them inside one turn

With only the two Android settings available (Device Notifications and Ongoing Agent Activity), there is no way to keep agent notifications while avoiding these repeated Done alerts

Impact

Major degradation or frequent failure

Version or commit

Android 1.3.0 (Google Play), desktop T3 Code Nightly 0.0.45-nightly.20261002.2584 (54084ae)

Environment

Windows 10 Pro 19045, Claude Code provider with background agents, Samsung Galaxy S21 Ultra 5G DS on Android 15, T3 Code Android app 1.3.0

Logs or stack traces

Session wake-ups not caused by the user (from the Claude Code session transcript):
task-notification: 29
background agent message (SendMessage): 26

Screenshots, recordings, or supporting files

No response

Workaround

Turning off Device Notifications stops it but also stops every agent notification. Turning Ongoing Agent Activity off does not help

Activity

  1. added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 2, 2026
  2. juliusmarminge commented on Oct 2, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Triage

    Thanks for counting the wake-ups, @Neonsy. Those 55 non-user wakes made this easy to pin down. It's confirmed on current main (54084ae1e6, the nightly you're on). It isn't an Android display bug, and turning off Ongoing Agent Activity can't stop it.

    Why each wake buzzes: when a background agent's SendMessage or a task notification arrives and no turn is open, Claude handles it as its own short turn. The session goes running, then ready. The relay maps that ready state to phase completed without checking whether background work is still live. With Device Notifications on, every fresh completed snapshot sends a Done: <project> push. It only skips a Done that's still queued when the thread is already running again, so wakes minutes apart each get their own alert. The working timer resetting comes from the same turn split. Foreground subagents don't do this because the parent turn stays open while they run.

    Web already handles this case. The sidebar stays on Working or Monitoring while background work is live, and the web completion alert waits until the thread is actually ready. The phone relay doesn't apply that same hold.

    Related, but not the same: open issue #13625 covers the short gap where a task notification clears liveness just before the wake-up turn starts, so one alert fires early. Open PR #14073 bridges only that handoff. It wouldn't collapse a run of spaced progress wakes into a single Done.

    Likely fix: keep the relay phase non-terminal while background liveness is working or monitoring, so these intermediate wakes don't publish completed.

    For now, the only workaround is the one you found: turning Device Notifications off, which unfortunately silences every agent alert.

  3. added
    via-triageFiled through npx t3 triage
    and removed
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 2, 2026
  4. juliusmarminge commented on Oct 2, 2026

    @juliusmarminge
    Member

    Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.

    V2 relay now uses the shared awareness projection, which keeps completed runs in running phase while wake-capable background work remains. The relay regression test verifies a completed run with a running background item sends no Done until that item ends.

    I’m closing this based on the current source and the evidence in this thread.

    Source reviewed.

    Source and regression coverage support closure of the V1 ready-to-completed bug. No device test was run; fresh V2 repeated notifications should include the background roster.

    If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.

  5. Neonsy commented on Oct 2, 2026

    @Neonsy
    Author

    Looking forward to it, especially cause of the cross provider subagent feature 😎

    Currently doing a custom proxy 🙃

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