This looks already resolved by #1588 (merged 2026-08-10, "Make the panic wipe confirmable and its outcome visible"). Checked current main:

The triple-tap logo shortcut calls AppChromeModel.requestPanicWipe(), which only sets showPanicConfirmation = true -- it never wipes directly (AppChromeModel.swift:126-128).
That raises the exact same confirmation dialog the Settings-pane panic button already used, so both entry points now ask before destroying anything (ContentHeaderView.swift:53-60, with an explicit comment: "a fumbled tap must never be able to wipe the device").
A wipe that doesn't fully commit also now shows a persistent banner (panicWipeBlocked), so "did it work?" isn't a guess either -- a bit beyond what this issue originally asked for.

One small leftover: AppInfoView.swift:123's panic_note string still has defaultValue: "...triple-tapping the bitchat/ logo does the same, instantly." in source, even though the actual catalog entry (Localizable.xcstrings) was correctly updated to drop "instantly" as part of #1588. The source-level default is just unused fallback text (the catalog entry always wins), not something users see, but worth a one-line fix so it doesn't mislead the next person reading the file. Happy to send that as a tiny follow-up if useful.

Looks safe to close from where I'm sitting -- flagging in case a maintainer wants to confirm and close it, or reopen if there's a gap #1588 didn't cover.

Feature Request: Confirmation Step or Config Option for Emergency Wipe #152

Description

Description:

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions