You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Android sends a new Done notification every time a background agent or task wakes the thread, with Ongoing Agent Activity off #14831
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
Install the Android app 1.3.0 from Google Play, sign in to T3 Connect, and link a desktop environment
In Settings → Notifications, keep Device Notifications on and turn Ongoing Agent Activity off
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
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
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.
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 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.
Activity
juliusmarminge commentedon Oct 2, 2026
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
SendMessageor a task notification arrives and no turn is open, Claude handles it as its own short turn. The session goesrunning, thenready. The relay maps thatreadystate to phasecompletedwithout checking whether background work is still live. With Device Notifications on, every freshcompletedsnapshot sends aDone: <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
workingormonitoring, so these intermediate wakes don't publishcompleted.For now, the only workaround is the one you found: turning Device Notifications off, which unfortunately silences every agent alert.
juliusmarminge commentedon Oct 2, 2026
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.
Neonsy commentedon Oct 2, 2026
Looking forward to it, especially cause of the cross provider subagent feature 😎