Problem
wagmi/tempo's webAuthn({ authUrl }) connector (pulled into this monorepo's catalog since wagmi: ^3.6.0 on 2026-04-06, #815) POSTs to /register/options · /register · /login/options · /login. The deployed keys.tempo.xyz serves the older tempo.ts/server Handler.keyManager surface (GET /challenge, GET|POST /:id). The route sets don't overlap — every HTTP-mode webAuthn ceremony 404s against it.
Reproduce
# What the connector actually sends:
curl -X POST https://keys.tempo.xyz/register/options \
-H 'content-type: application/json' -H 'origin: https://tempo.xyz' \
-d '{"name":"alice"}' -o /dev/null -w "%{http_code}\n"
# → 404
# What's actually deployed:
curl https://keys.tempo.xyz/challenge -o /dev/null -w "%{http_code}\n"
# → 200
Connector source calling the new routes: packages/core/src/tempo/Connectors.ts#L32 → accounts/core/adapters/webAuthn.js → WebAuthnCeremony.server({ url: authUrl }).
Why it hasn't paged
In-repo, apps/explorer filters connector.id !== 'webAuthn', and apps/fee-payer/playground uses KeyManager.localStorage() — ceremony stays browser-local, never hits the server. Third parties using apps/key-manager as a reference implementation with webAuthn({ authUrl: '…' }) will 404 immediately. apps/key-manager was last substantively updated 2026-02-13 (#593); the connector break landed in wagmi@3.6.0 on 2026-03-23.
Separately, pnpm-workspace.yaml doesn't pin accounts even though the wagmi/tempo connector dynamically import('accounts')s it at runtime — works today via transitive resolution but is fragile.
Fix
apps/key-manager/src/index.ts uses tempo.ts/server.Handler.keyManager. The server paired with current wagmi/tempo is accounts/server.Handler.webAuthn:
import { Handler, Kv } from 'accounts/server'
export default Handler.webAuthn({
kv: Kv.cloudflare(env.KEY_STORE),
origin: env.ALLOWED_ORIGINS, // new required param
rpId: env.RP_ID, // new required param
})
Plus add accounts to the workspace catalog. Reference shape of the two-required-params migration: officialunofficial/makechain#fbad6d46.
Environment
- wagmi 3.6.3 · @wagmi/core 3.4.4 · accounts 0.6.7 · tempo.ts 0.14.2
- Reproduced against live
https://keys.tempo.xyz on 2026-04-21
Problem
wagmi/tempo'swebAuthn({ authUrl })connector (pulled into this monorepo's catalog sincewagmi: ^3.6.0on 2026-04-06, #815) POSTs to/register/options·/register·/login/options·/login. The deployedkeys.tempo.xyzserves the oldertempo.ts/serverHandler.keyManagersurface (GET /challenge,GET|POST /:id). The route sets don't overlap — every HTTP-mode webAuthn ceremony 404s against it.Reproduce
Connector source calling the new routes:
packages/core/src/tempo/Connectors.ts#L32→accounts/core/adapters/webAuthn.js→WebAuthnCeremony.server({ url: authUrl }).Why it hasn't paged
In-repo,
apps/explorerfiltersconnector.id !== 'webAuthn', andapps/fee-payer/playgroundusesKeyManager.localStorage()— ceremony stays browser-local, never hits the server. Third parties usingapps/key-manageras a reference implementation withwebAuthn({ authUrl: '…' })will 404 immediately.apps/key-managerwas last substantively updated 2026-02-13 (#593); the connector break landed inwagmi@3.6.0on 2026-03-23.Separately,
pnpm-workspace.yamldoesn't pinaccountseven though the wagmi/tempo connector dynamicallyimport('accounts')s it at runtime — works today via transitive resolution but is fragile.Fix
apps/key-manager/src/index.tsusestempo.ts/server.Handler.keyManager. The server paired with currentwagmi/tempoisaccounts/server.Handler.webAuthn:Plus add
accountsto the workspace catalog. Reference shape of the two-required-params migration: officialunofficial/makechain#fbad6d46.Environment
https://keys.tempo.xyzon 2026-04-21