Hosted kernel panics (`process.rs:70: PID .. does not exist`) on CloseApp of an app blocked behind a permission modal

[tobyjaguar]

Environment: KeyOS v1.4.0 (eb2c2edb3), hosted simulator on macOS 26 (Darwin 25.6) arm64, driving it over the loopback usb-debug channel with the passport-drive protocol.

Steps:

1. Launch a third-party-class app whose UI thread makes a blocking, permission-gated call (Security::app_seed() -> GetAppSeed, grantOnFirstUse), so the OS consent prompt is showing and the app is blocked inside the call.
2. Send usb-debug CloseApp for that app's PID while the prompt is up.

What happens: the app cannot service the close request, gui-server force-terminates it, the app thread panics, and then the hosted kernel panics:

gui_server::close: Closing <app> (PID 29) timed out, terminating
thread panicked: Couldn't call ReceiveMessage: ServerNotFound
xous/kernel/src/arch/hosted/process.rs:70:17: PID 29 does not exist

The whole simulator is gone at that point.

Expected: the pending modal is dismissed (or the request denied) and the app closes; a forced termination should not take the kernel down.

Notes: this looks like a hosted-kernel process-teardown race rather than anything the app can avoid, although apps should not block their UI thread on a gated call in the first place. Observed twice on 2026-09-09.

[badicsalex]

Yeah this is definitely some kind of race/mixup with regards to terminate while there's an ongoing syscall.
It looks reproducible, so we'll test it in-house.