Una notificación no debería solo abrir la app, debería devolverte a la Session correcta

Normalmente describimos las notificaciones como un problema de entrega: si llegaron, qué tan rápido, si aparecen en la pantalla bloqueada. Para la programación remota con IA, ese marco se queda corto.

Si una notificación solo puede abrir la app, no ha cerrado realmente el bucle de feedback. El usuario todavía tiene que reconstruir la escena por su cuenta: qué máquina era, qué session, si Claude estaba pidiendo aprobación o avisando de una finalización, y si eso pertenecía a la tarea actual o a otra session que quedó en segundo plano hace un rato.

Eso no es un problema de copy. Tampoco es un problema de animaciones. Es un problema completo de sincronización de estado.

Por qué esto empeora en programación con IA

En muchas apps normales, una notificación corresponde limpiamente a un único objeto: un correo, un mensaje, un evento del calendario. Al tocarla, el destino es obvio.

La programación remota con IA no funciona así.

Puede que tengas tres sessions ejecutándose al mismo tiempo:

• una refactorizando un módulo
• una esperando resultados de tests
• otra detenida en una solicitud de aprobación

En ese contexto, "Claude te necesita" no significa nada. Lo que importa es:

• qué server emitió la notificación
• qué session la disparó
• en qué estado está esa session ahora mismo
• si el usuario ya estaba mirando esa session

Si falta cualquiera de esos elementos, la notificación se degrada a una interrupción vaga. Puede romper tu foco, pero no te ayuda a decidir qué hacer después.

Las notificaciones no solo fallan cuando se pierden

Muchos sistemas entienden la fiabilidad de notificaciones como "evitar que se pierdan". En flujos con varias sessions existe otro fallo igual de malo: la notificación llega, pero te devuelve al contexto equivocado.

Ese fallo es más sutil que una pérdida completa, y muchas veces más peligroso.

El usuario cree que ha vuelto al lugar correcto y sigue operando dentro de la session equivocada. En programación remota con IA eso puede significar:

• responder a Claude en el repo incorrecto
• aprobar la tarea equivocada
• interpretar el estado de una session como si fuera el de otra

A nivel de interacción parece un simple bug de navegación. A nivel de producto rompe la confianza en todo el flujo remoto.

Para que una notificación sea útil, el contexto tiene que sobrevivir a toda la ruta

Una notificación útil no es solo un payload de APNs. Tiene que atravesar toda la ruta sin perder identidad:

1. cuando se crea el hook event en el server, debe saberse qué tmux_session lo disparó
2. cuando el server hace broadcast de la notificación, debe incluir session
3. cuando el push relay hace dedupe, no puede deduplicar solo por project o distintas sessions se van a suprimir entre sí
4. cuando la app arranca en frío, tiene que mapear la identidad del server en el push al server guardado localmente
5. cuando llega la navegación final, tiene que reentrar al server correcto y seleccionar la session correcta, no caer en una pantalla por defecto

Si cualquier paso se convierte en "mejor intento", el comportamiento final se vuelve inestable.

Por eso los cambios relacionados con notificaciones en la 1.6.6 parecen repartidos entre iOS, Mac, el server y el push relay. En realidad están corrigiendo lo mismo: convertir la notificación en un punto de entrada ejecutable al contexto, no en un recordatorio genérico.

Cómo fallaba realmente el modelo anterior

Si abstraes el problema, el modelo anterior se rompía de cuatro formas típicas.

1. El evento de origen tenía session, pero la notificación no

El hook event del server sabía que venía de una tmux_session concreta, pero el broadcast solo decía "hay una notificación". A partir de ahí, el client solo podía caer en "volver a la session que ya estaba activa".

Eso crea una ilusión peligrosa: al tocar la notificación sí parece que algo navega, así que la función parece existir, pero el destino suele ser incorrecto.

2. Que funcione en foreground no significa que funcione en cold start

Muchos flujos de notificación parecen correctos mientras la app ya está viva. La ruta difícil es el arranque en frío, porque la app aún no ha restaurado todo su estado.

En ese momento, la lista de servers puede seguir cargando, el estado de navegación puede no existir todavía y los IDs locales pueden no coincidir con los identificadores del push. Si disparas la navegación demasiado pronto, obtienes uno de dos resultados:

• no se abre nada
• la app se abre, pero cae en el server o la session equivocados

3. La deduplicación trata dos sessions como si fueran un único evento

Si la clave de dedupe del push relay solo incluye server + project + event y no incluye session, dos sessions del mismo project que disparan eventos cerca en el tiempo pueden colapsar en una sola notificación.

Eso no parece un crash. Parece el tipo más difícil de reporte de usuario: "la tarea terminó, así que ¿por qué no me llegó ninguna notificación?"

4. El client confunde "session visible" con "session de origen"

Este es un error de modelado clásico en productos con varias sessions. La session en la que está enfocada la UI y la session que emitió la notificación no son el mismo concepto. Si tu modelo de estado no las separa, la navegación incorrecta es inevitable.

La 1.6.6 no arregló un botón. Arregló una ruta.

Lo importante de esta versión no es la frase "puedes navegar tocando la notificación". Lo importante es que por fin quedaron conectadas varias restricciones que antes estaban rotas.

1. Las notificaciones ahora llevan identidad de session

Antes un evento podía pertenecer claramente a la session B mientras el client solo sabía "pasó una notificación" y acababa cayendo de nuevo en la session A. En la 1.6.6 la identidad de session atraviesa el broadcast de notificaciones y el payload push. La alerta ya no significa solo "Claude quiere algo". Significa "repo-x / session-y quiere algo".

2. El cold start ya no pierde el deep link con tanta facilidad

La parte difícil nunca fue la transición visual. Fue el mapeo de identidades. El push trae la identidad del lado server; la app guarda IDs de objetos locales. El routing en cold start solo es real cuando esos dos sistemas de identidad se reconcilian.

En otras palabras: el problema no era "cómo cambiamos de pantalla", sino "cómo demuestra el sistema que este es el mismo server".

3. La entrega push deja de tratar session como metadata opcional

Si session falta en la clave de dedupe, dos sessions distintas del mismo project pueden suprimirse entre sí. Eso te dice algo importante: en flujos con IA, session no es metadata auxiliar. Es parte del significado de la notificación.

4. Las notificaciones locales, los push remotos y la navegación por fin hablan el mismo idioma

El mayor riesgo en cualquier pipeline de notificaciones es la deriva semántica:

• el server dice "esto es un hook event"
• el servicio push dice "esto es una alerta a nivel project"
• el client dice "bien, volveré a la página actual"

El valor real de la 1.6.6 es que esas capas empiezan a converger hacia el mismo objetivo: devolver al usuario al server y la session que produjeron el evento.

Por qué esto es un problema de producto, no solo de ingeniería

Puede parecer que hemos estado hablando de IDs, payloads y deep links. Por debajo de eso hay una decisión de producto más amplia:

¿Debe una notificación estar diseñada para devolver al usuario exactamente al lugar donde hace falta una decisión?

Si la respuesta es sí, entonces la tasa de entrega no basta. Una notificación tiene que cumplir tres condiciones al mismo tiempo:

• llegar
• caer en el lugar correcto
• permitir actuar de inmediato una vez allí

Con ese criterio, muchas notificaciones de software solo cumplen la primera.

Qué percibe realmente el usuario con este cambio

Si ignoras la implementación y miras solo el uso diario, la 1.6.6 mejora cuatro resultados visibles:

1. es menos probable que tocar una notificación caiga en la session equivocada
2. despertar la app desde la pantalla bloqueada o desde un estado terminado pierde menos contexto
3. un fallo transitorio de red tiene menos probabilidades de perder la notificación por completo
4. el estado de Live Activity es más fiable en rutas anómalas, aunque el caso límite de force-quit siga existiendo

Ninguno de esos cambios es llamativo por sí solo. Juntos responden a una pregunta más importante: ¿confías lo suficiente en el producto como para dejar varias sessions de IA corriendo en segundo plano?

La fiabilidad también exige honestidad con el borde

La 1.6.6 también reescribe la ruta de limpieza de Live Activity: reconcilia actividades obsoletas al relanzar, limpia referencias huérfanas y reduce las probabilidades de mostrar un falso estado "Finished" tras desconexiones temporales.

Pero hay un caso límite que no fingimos resolver en las release notes: si el usuario fuerza el cierre de la app de iOS, una Live Activity todavía puede seguir visible hasta el siguiente lanzamiento o un timeout del sistema.

Si escribiéramos eso como "arreglado por completo", el copy se vería mejor a corto plazo y el producto se sentiría menos fiable a largo plazo. Eso importa aún más en herramientas para desarrolladores, porque lo que vendes no es emoción. Es previsibilidad.

El objetivo real no es enviar más notificaciones

Un buen producto de IA remota no debería obligar al usuario a reconstruir "qué acaba de pasar" cada vez que llega una notificación.

El trabajo real de la notificación es hacer ese trabajo de recuperación de contexto por adelantado.

En programación remota con IA, la entrega es solo el billete de entrada. Que la notificación llegue con el contexto completo es lo que decide si se convierte en una entrada útil o en otra interrupción más.

La 1.6.6 no inventó las notificaciones ni inventó los flujos con varias sessions. Hizo algo más fundamental y más valioso: consiguió que esas dos cosas cooperen correctamente.