A Notification Should Bring You Back to the Right Session

We usually describe notifications as a delivery problem: did the alert arrive, how fast, can it appear on the lock screen. For remote AI coding, that framing is too shallow.

If a notification can only open the app, it has not actually closed the feedback loop. You still have to reconstruct the scene yourself: which machine was this, which session, was Claude asking for approval or reporting completion, and was it tied to the task you are looking at now or to a different session you left running earlier?

That is not a copywriting problem. It is not a transition-animation problem either. It is a full state synchronization problem.

Why This Gets Worse in AI Coding

In many ordinary apps, one notification maps cleanly to one object: an email, a message, a calendar event. Once you tap it, the destination is obvious.

Remote AI coding is not like that.

You might have three sessions running at once:

• one refactoring a module
• one waiting for test results
• another paused on an approval request

In that world, "Claude needs you" is not enough information. What matters is:

• which server emitted the notification
• which session triggered it
• what state that session is currently in
• whether the user is already looking at that session

If any of those are missing, the notification degrades into a vague interruption. It can break your focus, but it cannot help you decide what to do next.

Notifications Do Not Only Fail by Going Missing

Most systems treat notification reliability as "avoid dropping the message." In multi-session workflows there is another failure mode that is just as bad: the notification arrives, but returns you to the wrong context.

That failure is more subtle than complete loss, and often more dangerous.

The user thinks they are back in the right place, then continues operating in the wrong session. In remote AI coding that can mean:

• replying to Claude in the wrong repository
• approving the wrong task
• reading one session's status as if it belonged to another

At the interaction layer this looks like an ordinary jump bug. At the product layer it breaks trust in the whole remote workflow.

For Notifications to Be Useful, Context Has to Survive the Whole Path

A useful notification is not just an APNs payload. It has to survive a full chain without losing identity:

1. when the server hook event is created, it has to know which tmux_session triggered it
2. when the server broadcasts the notification, it has to include session
3. when the push relay deduplicates events, it cannot dedupe by project alone or different sessions will suppress each other
4. when the app cold-starts, it has to map the push's server identity back to the locally saved server
5. when navigation happens, it has to re-enter the right server and then select the right session instead of landing on a default screen

If any step falls back to "best guess," the final behavior becomes unstable.

That is why the notification-related changes in 1.6.6 look spread across iOS, Mac, the server, and the push relay. They are all fixing the same thing: turning a notification into an executable context entry point instead of a generic reminder.

How the Old Model Actually Failed

If you abstract the problem, the old model broke down in four common ways.

1. The Source Event Had a Session, but the Notification Did Not

The hook event on the server knew it came from a specific tmux_session, but the broadcast notification only said "there is a notification." Once that happened, the client could only fall back to "go to whatever session is already active."

That creates a dangerous illusion: tapping the notification does appear to navigate somewhere, so the feature looks present, but the destination is often wrong.

2. Working in Foreground Is Not the Same as Working on Cold Start

Many notification flows seem correct while the app is already alive. The harder path is cold start, because the app has not restored its full state yet.

At that point, the server list may still be loading, navigation state may not exist yet, and local IDs may not match the identifiers in the push payload. If you drive navigation too early, you get one of two results:

• nothing opens
• the app opens, but lands on the wrong server or session

3. Deduplication Accidentally Treats Two Sessions as One Event

If a push relay dedupe key only includes server + project + event and does not include session, then two sessions in the same project that fire close together can collapse into one notification.

That does not look like a crash. It looks like the hardest kind of user report to debug: "the task completed, so why did I never get notified?"

4. The Client Confuses "Visible Session" with "Source Session"

This is a classic modeling mistake in multi-session products. The session the UI is currently focused on and the session that emitted the notification are not the same concept. If your state model does not separate them, wrong navigation is inevitable.

1.6.6 Did Not Really Fix a Button. It Fixed a Path.

The important part of this release is not the sentence "tap notifications to navigate." The important part is that several constraints are finally connected.

1. Notifications Now Carry Session Identity

Previously, an event could clearly belong to session B while the client only knew "a notification happened," then defaulted back to session A. In 1.6.6, session identity is carried through notification broadcasts and push payloads. The alert no longer means "Claude wants something." It means "repo-x / session-y wants something."

2. Cold Start No Longer Loses the Deep Link

The hard part was never the UI transition. It was identity mapping. Pushes carry server-side identity; the app stores local object IDs. Cold-start routing only becomes real once those two identity systems are reconciled.

In other words, the problem was not "how do we jump pages." It was "how does the system prove this is the same server."

3. Push Delivery Stops Treating Session as Optional Metadata

If session is missing from the dedupe key, then two different sessions in the same project can suppress each other. That tells you something important: in AI workflows, session is not auxiliary metadata. It is part of the notification's meaning.

4. Local Notifications, Remote Pushes, and Navigation Finally Speak the Same Language

The biggest risk in any notification pipeline is semantic drift:

• the server says "this is a hook event"
• the push service says "this is a project-level alert"
• the client says "fine, I will just return to the current page"

The real value of 1.6.6 is that those layers are now converging on one target: return the user to the server and session that produced the event.

Why This Is a Product Problem, Not Just an Engineering Problem

It may sound like we have been talking about IDs, payloads, and deep links. Underneath that, though, there is a broader product decision:

Should a notification be designed to return the user to the exact place where a decision is needed?

If the answer is yes, then delivery rate is not enough. A notification has to satisfy three conditions at once:

• it arrives
• it lands in the right place
• once it lands, the user can act immediately

By that standard, many notifications in software products only satisfy the first condition.

What Users Actually Feel from This Change

If you ignore the implementation and only look at day-to-day usage, 1.6.6 improves four visible outcomes:

1. tapping a notification is less likely to land in the wrong session
2. waking the app from the lock screen or from a terminated state is less likely to lose context
3. transient network failures are less likely to drop a notification outright
4. Live Activity state is more trustworthy on abnormal paths, even though the force-quit edge case still exists

None of those changes are flashy in isolation. Together they answer a more important question: do you actually trust the product enough to leave multiple AI sessions running in the background?

Reliability Also Means Being Honest About the Boundary

1.6.6 also rewrites the Live Activity cleanup path: stale activities are reconciled on relaunch, orphan references are cleared, and temporary disconnects are less likely to show a false "Finished" state.

But there is one edge case we did not pretend to solve in the release notes: if the user force-quits the iOS app, a Live Activity can still remain visible until the next launch or a system timeout.

If we wrote that up as "fully fixed," the copy would look cleaner in the short term and the product would feel less trustworthy in the long term. That matters even more for developer tools, because the thing you are selling is not mood. It is predictability.

The Real Goal Is Not More Notifications

A good remote AI product should not require the user to reconstruct "what just happened" every time a notification arrives.

The real job of the notification is to do that context recovery work in advance.

For remote AI coding, delivery is only the ticket to entry. Whether the notification arrives with the full context attached is what determines whether it becomes a useful input or just another interruption.

1.6.6 did not invent notifications, and it did not invent multi-session workflows. It did something more fundamental and more valuable: it made those two things cooperate correctly.