Summary

tempo request cannot pay a one-time MPP charge when the configured Tempo Wallet uses a P-256 access key created from a passkey account. The request reaches a valid 402 Payment Required challenge, but credential creation fails client-side with:

code: E_PAYMENT
message: Cannot read properties of undefined (reading 'toLowerCase')
retryable: false

The same services work when tempo request is given a temporary secp256k1 private key, which suggests the failure is specific to the stored P-256 wallet/access-key identity path rather than the MPP challenge or provider.

Environment

• Tempo launcher: 1.10.1 (b9aff905a341c978dd78518e6cc7ada6b2395722)
• tempo-wallet: 0.6.5
• tempo-request: 0.6.5
• OS: Linux x86_64
• Network: Tempo mainnet, chain ID 4217
• Wallet type: passkey
• Access key type in ~/.tempo/wallet/store.json: p256

The environment uses an HTTP proxy, so commands below include NODE_USE_ENV_PROXY=1. That resolves normal HTTP access; the toLowerCase error occurs later during MPP credential/payment creation.

Reproduction

1. Log into a Tempo passkey wallet and authorize the CLI with a limited access key.
2. Confirm the CLI is ready:

NODE_USE_ENV_PROXY=1 tempo wallet whoami -t

Output includes:

ready: true
key:
  chain_id: 4217
  network: tempo
  spending_limit:
    unlimited: false
    limit: "1.000000"

3. Confirm a valid Browserbase MPP challenge:

NODE_USE_ENV_PROXY=1 tempo request -i --dry-run \
  -X POST \
  --json '{"query":"Tempo blockchain documentation","numResults":3}' \
  https://mpp.browserbase.com/search

The response is 402 with a valid Tempo charge challenge containing:

method="tempo"
intent="charge"
currency="0x20C000000000000000000000b9537d11c60E8b50"
methodDetails.chainId=4217
amount="10000"

4. Execute the request:

NODE_USE_ENV_PROXY=1 tempo request -t --max-spend 0.02 \
  -X POST \
  --json '{"query":"Tempo blockchain documentation","numResults":3}' \
  https://mpp.browserbase.com/search

Actual result:

code: E_PAYMENT
message: Cannot read properties of undefined (reading 'toLowerCase')
retryable: false

The identical failure reproduces against Exa's /search MPP endpoint. Neither failed attempt charged the wallet.

Expected behavior

tempo request should use the configured P-256 access key to create the Tempo charge credential, pay within its authorized spending limit, and return the service response.

Control / workaround

Funding a temporary secp256k1 signer and invoking the same Browserbase request via TEMPO_PRIVATE_KEY succeeds and returns search results. This confirms the endpoint, request schema, challenge, token, recipient, and chain are valid.

Possible implementation clue

In src/commands/request.ts, storedAccessKeyIdentity(...) contains explicit reconstruction for p256 and secp256k1 access keys, but it appears to be defined/exported without being called by resolvePaymentIdentity(...). The normal request path instead creates a generic provider identity. This may leave a field undefined when the MPP Tempo method normalizes an address/token with toLowerCase().