Skip to content

fix: recognize MetaMask Flask (io.metamask.flask) as native MetaMask#336

Merged
adonesky1 merged 2 commits into
mainfrom
adonesky/connect-flask-eip6963-support
Jun 23, 2026
Merged

fix: recognize MetaMask Flask (io.metamask.flask) as native MetaMask#336
adonesky1 merged 2 commits into
mainfrom
adonesky/connect-flask-eip6963-support

Conversation

@adonesky1

@adonesky1 adonesky1 commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Explanation

MetaMask Connect only treated io.metamask (production extension) and io.metamask.mobile as native MetaMask EIP-6963 providers. MetaMask Flask announces itself with rdns: 'io.metamask.flask', which was missing from every allowlist. As a result hasExtension() returned false when only Flask was installed, so MetaMaskConnectMultichain.connect() fell through to the MWP transport (QR code / mobile deeplink) instead of using the locally-installed Flask extension — even though the browser postMessage transport (metamask-contentscript) works with Flask just fine. The legacy @metamask/sdk recognized Flask (METAMASK_EIP_6369_PROVIDER_INFO.RDNS = ['io.metamask', 'io.metamask.flask']), so to consumers this looked like a regression.

This surfaced during a live-stream dApp build that migrated to MetaMask Connect + wagmi while using Flask: the connection only worked after manually selecting wagmi's auto-discovered io.metamask.flask connector, which bypasses the Connect SDK entirely.

What changed

Primary fix — add io.metamask.flask to the recognized native MetaMask RDNS values in the three places that gate Flask:

  • packages/connect-multichain/src/domain/platform/index.tsNATIVE_METAMASK_EIP6963_RDNS (drives hasExtension(), which selects the extension vs MWP transport).
  • packages/connect-evm/src/eip6963.tsMETAMASK_EIP6963_RDNS (announce-suppression so the SDK doesn't announce a duplicate MetaMask entry alongside Flask).
  • integrations/wagmi/metamask-connector.ts — the metaMask() connector's rdns (plus the two playground copies for parity).

Docs (nice-to-have) — the metamask-connect skill never mentioned Flask. Added a troubleshooting entry, updated the wagmi setup/migration notes, and fixed related doc comments + the connect-evm README.

Result

With only Flask installed on desktop web, the Connect connector now uses the browser extension transport (no QR/MWP fallback) and connects like the production extension.

References

  • WAPI-1559
  • Legacy behavior: @metamask/sdk packages/sdk/src/constants.ts (METAMASK_EIP_6369_PROVIDER_INFO.RDNS)

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

MetaMask Connect only recognized `io.metamask` and `io.metamask.mobile`
as native MetaMask EIP-6963 providers, so MetaMask Flask
(`io.metamask.flask`) was not detected as an installed extension.
`hasExtension()` returned false with only Flask installed, causing
connect() to fall through to the MWP/QR transport instead of using the
local Flask extension — even though the browser postMessage transport
works with Flask. The legacy `@metamask/sdk` recognized Flask, so this
behaved like a regression.

Add `io.metamask.flask` to the recognized native MetaMask RDNS values in:
- connect-multichain extension detection (NATIVE_METAMASK_EIP6963_RDNS)
- connect-evm EIP-6963 announce suppression (METAMASK_EIP6963_RDNS)
- the wagmi metaMask() connector's rdns (+ playground copies)

Also document Flask handling in the metamask-connect skill and update
related doc comments / README.
@adonesky1 adonesky1 requested a review from a team as a code owner June 23, 2026 18:10
@adonesky1 adonesky1 merged commit 29f3ba9 into main Jun 23, 2026
19 of 20 checks passed
@adonesky1 adonesky1 deleted the adonesky/connect-flask-eip6963-support branch June 23, 2026 20:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants