SDK 1.0.0 `foundation sideload` fails its pre-launch check on KeyOS 1.4.0-beta3: `get_allowed_publisher_count: expected 2 payload bytes, got 4` (upload succeeds; `--no-run` + `launch-app` works)

[tobyjaguar]

Environment: Foundation SDK 1.0.0 (foundation 1.0.0, bundled foundation-passport-drive), KeyOS 1.4.0-beta3 (bootloader 0.2.1; get-version → 1.4.0-beta3), retail Passport Prime, Developer Mode on, device unlocked. Host: Ubuntu 22.04.5 (kernel 7.0.11), libusb via /dev/bus/usb with a udev rule for 1307:0165.

Summary

On 1.4.0-beta3 the usb-debug channel works — list-ports, get-version, get-process-list, screenshot, logs, MCP connect/get_developer_mode all fine. But foundation sideload aborts after a successful upload, at the pre-launch publisher check:

Loaded 7f6dcb0d47017e87afaf6548fff8c249 into keyos/sideloaded-apps/7f6dcb0d47017e87afaf6548fff8c249 (app.elf: 4324996 bytes, manifest.json: 3310 bytes, icon.bin: 46712 bytes, icon-dark.bin: 46712 bytes, resources: 1 files / 3456056 bytes).
Error: Sideload preflight failed before launch. On Passport Prime, import the matching certificate in Settings > Apps > Allowed Publishers, then reconnect USB and try again. Reason: get_allowed_publisher_count: expected 2 payload bytes, got 4

The MCP tool shows the same: get_allowed_publisher_count → expected 2 payload bytes, got 4. The advice in the error is misleading in this case — the publisher is allowed (Settings > Apps > Allowed Publishers shows 1, and the same app installs and launches fine); the failure is a wire-format mismatch, not a missing certificate.

Looks like the firmware widened the GET_ALLOWED_PUBLISHER_COUNT response from u16 to u32 (or added a field) after the SDK 1.0.0 passport-drive was cut. Either the 1.0.x passport-drive should accept both widths, or the next SDK should ship the matching client.

Workaround (works)

foundation sideload --no-run                                   # upload succeeds, exit 0
foundation-passport-drive launch-app 7f6dcb0d47017e87afaf6548fff8c249   # "App launched with PID 41"
foundation-passport-drive screenshot -o after.png              # shows the app

So the only thing broken is the automatic launch path; everything else in the agentic loop (screenshots, taps, logs, MCP) is usable today.

Two smaller notes from the same session

1. Updating firmware resets Developer Mode to off (beta1 → beta3 via Firmware Recovery). Probably intentional (it's an encrypted setting), but worth a line in the SDK docs: "after a firmware update, re-enable Developer Mode; the debug interface is only enumerated while it's on." The interface appears live when the toggle is flipped (the device re-enumerates; no replug needed on beta3).
2. On 1.4.0-beta1 the debug interface never enumerated for me even with Developer Mode on — the config descriptor had bNumInterfaces = 2 with interfaces numbered 1 (MSC) and 2 (HID), i.e. slot 0 registered but withheld — across replug, power-cycle, unlocked replug, and toggle off→on. Same SDK, same host, same device on beta3: Developer Mode toggle → 3 interfaces (0 MSC, 1 HID, 2 vendor 0xFF) and everything connects. I didn't capture more from beta1 before upgrading; mentioning it only in case it matches something fixed between beta1 and beta3. (Simulator: expose InjectTouch/InjectKey through the simulator-cli control protocol (hands-off UI automation) #13 reports it working on beta1 from macOS, so it may have been state-specific.)

Also: the file install path is solid

foundation pack → .app + publisher .crt on a USB drive → Settings > Apps > Allowed Publishers → Install App worked first time for two apps, and both survived the beta1→beta3 recovery update. Nice.

Publisher fingerprint for reference: b5df4739d8c9e8fce8ff7d2a479a6dc6b7dada3704fd394853221cfc410de249. Happy to test a fixed passport-drive build.

[georgesFoundation]

Hello, you should reinstall the SDK from the curl command in the official doc "Getting Started" page. It has been fixed.

Note that currently reinstalling SDK will show you the same version 1.0.0, but it is in fact a v1.0.0-beta2 (we don't handle well the pre release showing for now).

Thanks for this great report that confirm many other SDK bugs are fixed at your side. Can't wait to see what kind of app you want to build !

[tobyjaguar]

Confirmed fixed — verified end-to-end on hardware. Thanks for the quick turnaround.

Setup: reinstalled from https://sdk.foundation.xyz/latest/install.sh, same Passport Prime on KeyOS 1.4.0-beta3, same publisher cert (b5df4739…410de249), Developer Mode on. Nothing changed but the SDK.

foundation sideload (no --no-run) now clears the pre-launch check and launches:

Checking allowed publisher certificate...
Checking passport-drive MCP control...
passport-drive MCP control connected.
Loaded 67919a16cb73cf18293a8a1f34d09d5a into keyos/sideloaded-apps/67919a16cb73cf18293a8a1f34d09d5a
Launching passport-nft-viewer via passport-drive MCP...
Launch request accepted: App launched successfully with PID 41
Sideload complete!

Confirmed running via get-process-list (PID 41) and screenshot. Closing this out.

For anyone landing here from a search: the client-side change is visible in the binary — foundation-passport-drive went from expected 2 payload bytes to expected 4 payload bytes, i.e. the u16→u32 widening.

---

Two notes from the same session, neither worth its own issue:

1. There is a way to tell the re-cut apart from the original 1.0.0. You mentioned the pre-release version doesn't render. It does surface in --version, as a build hash:

bundle	foundation --version
original 1.0.0 (installed here 2026-08-11)	foundation 1.0.0
current re-cut	foundation 1.0.0 (039881500da0)

So "run foundation --version; if there's no hash in parentheses you're on the older bundle" works as a triage instruction until pre-release versions display properly. Might save you a round-trip on the next report.

2. The re-cut binaries now require glibc 2.38 — intentional? The previous ones ran on this host directly; these don't:

/usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found

Host is Ubuntu 22.04 LTS (glibc 2.35). No problem in the supported workflow — everything runs inside nix develop — and foundation-passport-drive already needed libudev.so.1 so it was shell-only regardless. Flagging it only because 22.04 is still in LTS support, and because the templates' .mcp.json invokes foundation-passport-drive by bare name, which now requires the editor or agent to have been launched from inside the Nix shell. If that's a deliberate toolchain bump, ignore me.

Separately, I filed a small follow-up on the Developer Mode reset behaviour — it turned out to be broader than the note I put in this issue. It's a correction to my own report rather than anything to do with this bug.