[Bug]: iOS trash button does not remove a persisted environment#12012

Triage

Confirmed on current main (935c55b37). This is a real iOS mobile bug, not a wash of #9761. A direct saved environment can be restored from Keychain after delete+reinstall, and the Environments trash control never presents its confirm, so the row cannot be forgotten.

What the code does

Settings → Environments lists catalog presentations, including offline/disabled ones. A direct (non-relay) row is ConnectionEnvironmentRow: expand, then the red trash. That is the control in this report, not the T3 Connect long-press path.

Trash calls onRemoveEnvironmentPress in apps/mobile/src/state/use-remote-environment-registry.ts. The only skip before Alert.alert("Remove from this device?", …) is a lookup in connectedEnvironments. The list and the handler share that array, so a visible row should match — but the silent return is still a landmine (any identity/stale-closure miss eats the tap with no feedback).

If the alert did show and the user confirmed, remove is real: environmentCatalog.remove → EnvironmentRegistry.remove → removeConnectionFromCatalog → SecureStore t3code.connection-catalog.v1.

That document is why reinstall does not help. Mobile persists the catalog through Expo SecureStore / iOS Keychain (catalog-store.ts, mobile-secure-storage.ts). app.config.ts also sets keychain-access-groups (#3665). iOS keeps those items across delete+reinstall. Settings → Client Storage only clears thread/cache data; it does not drop the catalog.

Why the confirm never appears

Two stacked presentation problems, both still on main:

1. Settings → Environments is a nested formSheet. SettingsSheet uses form-sheet presentation, then a headerless stack, then Environments. RN Alert.alert presents a UIAlertController from the key window — a known miss inside react-native-screens form sheets / nested nav. The confirm is invoked and never visible, which matches “tap trash, nothing happens.” Other Settings alerts sit on the sheet root; this is the only confirm on the pushed Environments screen.
2. The trash lives in a Reanimated FadeIn block that mounts only after expand (ConnectionEnvironmentRow). First taps during layout/FadeIn can be dropped.

Either one is enough for a dead trash on a stale row. The Keychain restore just makes it permanent: the endpoint is offline, Off still leaves the row, reinstall brings it back, and the only forget control is the one that does not present.

First engineering step: reproduce on device/simulator — Settings formSheet → Environments → expand an offline direct row → trash. Confirm whether Alert.alert is called and whether a UIAlertController is sitting behind the sheet.

Related, not duplicates

No open PR claims the direct-row confirm / persist path.

Suggested fix

Keep this as a bugfix on apps/mobile (direct Environments row only):

1. Always present confirm. Do not return when the list lookup misses; fall back to the environment id for the label.
2. Present the confirm in-tree (showConfirmDialog / a sheet-local modal), not Alert.alert. ConfirmDialogHost already exists because native dialogs are unreliable on one platform; the Settings formSheet needs the same treatment on iOS.
3. Surface a persist failure. If SecureStore.setItem / remove fails, show an error and keep the row. A successful in-memory remove plus a failed Keychain write is how a “removed” environment comes back on the next launch.
4. Tests: offline direct environment → trash presents confirm; confirm → catalog no longer contains that target; failed SecureStore write → error, row remains.
5. Optional escape hatch in Client Storage / Diagnostics: “Forget saved environments on this device,” because Keychain survives reinstall and there is no wipe today.

Do not fold this into #9761 (relay deregister) or #8923 (catalog backup).

Workaround

None in-app. Off only silences the row. Client Storage does not drop credentials. Delete+reinstall restores the same catalog. Until a build with the fix ships, the stale direct row can only be ignored.

Classification: bug · accepted · minor–medium (iOS; cannot forget a Keychain-restored direct environment)
Labels: add accepted, via-triage; keep bug; remove needs-triage
Discord tags: mobile-ios, persistence, ui

I'd like to work on this. My understanding is that the Environments trash control never presents its "Remove from this device?" confirmation, so it never removes the saved direct environment; the fix should present the confirmation and delete the persisted environment/catalog entry, validated on iOS. Is it available for me to take?

I'd like to take this. I'll follow the direction in the maintainer triage above and open a focused PR with before/after evidence, noting the model and harness used.

Opened a PR for this: https://github.com/pingdotgg/t3code/pull/18228

It makes the trash always present the confirm (labelled by id if the row is missing from the connected list) and reports a failed removal instead of dropping it. I could not reproduce the invisible-confirm theory on the iOS 26.3 or 18.3 simulators with current main, so the PR leaves the native Alert.alert in place. The details, including what I forced and could not check, are in the PR description.

Model and harness: Claude Sonnet 5.5 via Claude Code in T3 Code.

Tried this on an iOS simulator and could not reproduce it.

What was run

• T3 Code Preview, static iOS simulator build of b5a226e49c (app version 2.0.0). The Environments, trash and confirm code (ConnectionEnvironmentRow, onRemoveEnvironmentPress in use-remote-environment-registry.ts, the catalog store) is unchanged between that commit and current main (ed3f965e07).
• Remote iOS simulator. The Keychain catalog held one direct saved environment ("Stale offline direct environment", route http://127.0.0.1:1) that was offline: the home header showed "Reconnecting…" and the details showed Cause: network, 8 failed attempts.
• Settings → Environments (1) → the environment → Expand details → red trash.

What happened

1. The trash presented "Remove from this device?" over the Settings sheet (attached).
2. Remove → "This environment is no longer saved on this device."
3. After force-quitting and relaunching, the app showed "No environments connected", so the entry was gone from the Keychain catalog too.

So on this build, an offline direct environment restored from the Keychain can be removed.

What would help

• The exact app version and build: Settings → About, or the App Store version line. The report says the build was not shown, and the September release is several versions behind.
• Whether it still happens after updating to the current App Store release.
• A screen recording of the tap on the trash, and your iOS version.

Closing: no reply in 7 days after we asked for more information. Comment with the missing details and we will reopen.