Auto-updater (ShipIt) doesn't relaunch the desktop app after installing an update — breaks anything relying on the app staying open

Update: pulled the full ShipIt update history (log goes back to 2026-05-12). This is a regression, not a longstanding design gap.

Every update from 2026-05-16 through 2026-07-10 (11 consecutive updates) successfully relaunched the app — each shows the full sequence: Installation completed successfully → Detected this as a launch request → Successfully launched application.

Starting 2026-07-13, relaunch starts failing intermittently, then consistently:

• 2026-07-13 07:20 — no relaunch
• 2026-07-13 22:58 — relaunched fine (last successful one observed)
• 2026-07-14 07:15 — no relaunch
• 2026-07-14 17:28 — no relaunch
• 2026-07-16 07:15 — no relaunch
• 2026-07-17 07:15 — no relaunch

So something changed in the update/relaunch path between 7/10 and 7/13 that stopped the app from reliably relaunching itself post-install. Worth checking what shipped in that window — this should be reproducible by diffing the updater behavior (or its call site) across those builds.

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/50582

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Re: the possible-duplicate flag against #50582 — related but not the same bug, and I don't think this should auto-close as a dup.

#50582 found two different failure modes: the update sometimes silently "succeeds" without the installed version actually changing, and sometimes SQRLUpdater fails invisibly before ShipIt even runs (no log trace at all). That issue was closed by the stale-bot for inactivity, not because it was fixed.

What I reported here is more specific: the bundle swap genuinely completes correctly (confirmed via file timestamps — the new version really does get installed), but the app fails to relaunch itself afterward. That's a distinct symptom from either of #50582's failure modes.

More importantly, this report has something #50582 never established: an exact regression window. Every update from 2026-05-16 through 2026-07-10 (11 consecutive updates) relaunched the app successfully — full log evidence in the original report. It started failing 2026-07-13 and has failed on every instance since. That's the kind of detail that should help pin down which change broke it, and it'll get lost if this gets merged into a year-old stale-closed issue with a different symptom description.

Happy to have both issues cross-referenced, but would ask that this one stay open on its own given the regression-window evidence.

Correction/expansion — my original report undersold this. Turns out the auto-updater relaunch failure is not the primary cause of the daily scheduled-task failures I was chasing; it's at most one contributing factor among several.

Evidence: a separate local watchdog (~/.claude/tools/morning-watchdog.sh, checks pgrep -f "Claude.app/Contents/MacOS/Claude") has been logging three checks a day (5:35, 6:50, 7:15 AM) for the past 6 days. Every single check confirms the app process WAS running:

2026-07-12 05:35: Claude running OK
2026-07-12 06:50: Claude running OK
2026-07-12 07:15: Claude running OK
2026-07-12 07:15: ESCALATION - no brief stamp for 2026-07-12, notified
[same pattern 07-13 through 07-17 — 6 consecutive days]

So the app being open and responsive is NOT sufficient for a scheduled task (via claude --resume / scheduled-tasks feature) to actually fire and complete on its own. Something in the scheduled-task dispatch/execution path is failing independently of whether the app process itself is alive — that's outside what client-side logs can show me; would need Anthropic's internal scheduler telemetry to actually diagnose.

Leaving the original relaunch-bug findings in place since they're still accurate and still a real (if partial) contributing cause on the specific days an update landed at the trigger time. But the broader, more consistent failure mode across 6 straight days needs separate investigation into the scheduled-task dispatch mechanism itself, not just app-process liveness.

This issue has not been resolved. Sent from my iPhoneOn Jul 17, 2026, at 7:58 AM, github-actions[bot] @.***> wrote:github-actions[bot] left a comment (anthropics/claude-code#78538)
Found 1 possible duplicate issue:

#50582

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.Message ID: @.***>