Developer Mode resets on every power cycle, and the usb-debug error never mentions it (KeyOS 1.4.0-beta3)

[tobyjaguar]

Environment: Passport Prime (retail), KeyOS 1.4.0-beta3, Foundation SDK 1.0.0 re-cut (foundation 1.0.0 (039881500da0)). Host: Ubuntu 22.04.5, libusb via a udev rule for 1307:0165.

Summary

Developer Mode switches itself off on a plain power cycle, not only across a firmware update. While it's off the vendor debug interface isn't enumerated, so every foundation-passport-drive / foundation sideload / foundation logs command fails with an error that never mentions Developer Mode:

Error: Failed to open USB device

Caused by:
    no vendor debug interface (class 0xFF) with both bulk endpoints

That message sends you looking at udev rules, cables, and libusb permissions — all the things a Linux USB failure usually means — when the actual cause is a device-side toggle that silently reverted.

This is a correction to note 1 of #14, where I reported the reset as firmware-update-related. That understated it: an update is a rare event, a power cycle is routine, so in practice you can hit this any session.

Reproduce

1. Enable Settings > Apps > Developer Mode. Confirm the debug interface appears — the device re-enumerates live, no replug needed.
2. Power the device off and on.
3. Unlock, plug in USB, run any passport-drive command → the error above.
4. Settings > Apps > Developer Mode is off. Toggle it on and the same command succeeds immediately.

The reliable host-side diagnostic

The USB interface count tells you which state you're in before you touch anything else:

$ lsusb -d 1307:0165 -v 2>/dev/null | grep -E "bNumInterfaces|bInterfaceClass"
  bNumInterfaces          2          # Developer Mode OFF
    bInterfaceClass         8 Mass Storage
    bInterfaceClass         3 Human Interface Device

  bNumInterfaces          3          # Developer Mode ON
    bInterfaceClass         8 Mass Storage
    bInterfaceClass         3 Human Interface Device
    bInterfaceClass       255 Vendor Specific Class

What we'd like

Either of these would have saved the detour, and the first is a one-liner:

1. Name Developer Mode in the error. Something like: no vendor debug interface (class 0xFF) found — check that Developer Mode is enabled (Settings > Apps > Developer Mode); it resets when the device is powered off. The tooling already knows this is the only thing that exposes the interface, so it's the highest-probability cause by a wide margin.
2. Document the power-cycle behaviour alongside the firmware-update case in the sideload/usb-debug docs.

If the reset is deliberate — I'd assume so, given it gates a debug channel and is presumably an encrypted setting — then this is purely a discoverability request, not a behaviour change. Happy either way; the toggle itself seems reasonable.

[badicsalex]

The root cause of this is that the developer mode setting is stored on the encrypted firmware, which is only mounted after the first unlock after a reboot. After the unlock, the setting is read and the interface is enabled.
This is for security reasons: putting the devmode switch into non-encrypted regular flash would allow a theoretical attacker to desolder the flash chip, modify the files and resolder it, enabling devmode and exposing an attack surface on the unlock screen.

I'm not sure what we can do about this without compromising security, we will think about it.

[badicsalex]

In fact, for security reasons, multiple devmode commands are deliberately disabled when the screen is locked, especially screenshot and simulated taps, so even if you managed to reset automatically and it came up, you wouldn't be able to log in automatically.

I'm afraid that since this is a hard policy stance, auto-reset + auto-unlock will never be possible on production units.

[tobyjaguar]

Thanks — the desoldering rationale makes sense and we're not asking for that to change.

One clarification, because I think the reset may be a separate thing from the mount timing. The key detail I didn't make clear enough in the original repro: I unlocked first, then looked at Settings.

1. Developer Mode on, 3 interfaces, foundation sideload working.
2. Full power cycle.
3. Unlock, stay on the home screen — Settings never opened.
4. bNumInterfaces = 2 (Bus 003 Device 016). Reseat the cable → still 2 (Device 017, so a genuinely fresh enumeration, not a stale config being reused).
5. Then open Settings > Apps: Developer Mode reads off.

Step 5 is the one I'd point at. At that moment the device was already unlocked, so the encrypted volume was mounted and Settings should have been showing the real stored value — and it showed off. Toggling it on brings the interface back immediately, as always.

So: is Developer Mode meant to persist across a power cycle, or is it cleared at every boot by design?

If it's cleared by design, that's a simpler and honestly better story than the mount timing — "the debug surface never persists across a boot" is easy to document and a good default. If it's meant to persist, then something separate from the mount gating is clearing it on 1.4.0-beta3.

I'll flag that I can't distinguish those two from the outside; both are consistent with what I measured. Happy to run anything specific on the device if it helps.

---

Scope note, since the second comment answers something broader than this issue: we're not asking for auto-reset or auto-unlock, and we agree with the policy. That request came from #16, not here — I've withdrawn my part of it there.

This issue only ever asked for two things, and neither needs a firmware change or touches the security boundary:

1. Name Developer Mode in the error. This one is purely host-side: foundation-passport-drive can already see the device on 1307:0165 with 2 interfaces instead of 3, which is an unambiguous "device is present, debug interface is not enabled" signal. Today the message is no vendor debug interface (class 0xFF) with both bulk endpoints, which sends you looking at udev rules, cables and libusb permissions — all the usual suspects for a Linux USB failure — when the cause is a device-side toggle.
2. Document the behaviour, whichever of the two above turns out to be intended.

If anything, a hard policy stance makes both of these more worthwhile: if a developer will hit this state forever, it should be discoverable the first time rather than the third.

[badicsalex]

1. Yeah, that makes sense. Created a ticket for that.
2. I checked, and resetting devmode on boot to false is in fact intentional currently. This is separate from the fact that it's on the encrypted volume, there's specific code to switch it off. I'll ask around if we want to change that or not.

[tobyjaguar]

Perfect — that answers it, thanks for going and checking.

For anyone finding this later: the boot-time reset is deliberate and separate from the encrypted-volume gating, so the rule is simply that Developer Mode does not survive a power cycle, and re-toggling it by hand is the only way back — unlocking and replugging don't help.

One framing for the internal discussion, since you've now separated the two mechanisms: they defend different things. The encrypted volume is what prevents the desolder-and-flip attack, because it stops devmode being readable before unlock — and that protection holds whether or not the boot reset exists. The reset instead guards against a device sitting in devmode indefinitely after someone enabled it once for a sideload and forgot. Both are reasonable, but only the second is really in scope if you change the reset.

From the third-party dev side my preference is mild, and weaker than it was yesterday: once the error names Developer Mode, this goes from "confusing" to "one toggle after a reboot", which is completely livable. If you keep it, a line in the sideload docs is all it needs.

Happy to test the error-message change on Linux / 1.4.0-beta3 whenever it lands.