[jplhomer]

Note

The table form is gated server-side. Until the platform enables it for an app, deploying an extension that declares [extensions.capabilities.network_access] allowed_sources fails with a server error. network_access = true and false aren't affected.

WHY are these changes introduced?

UI extensions (checkout, customer accounts, admin) can turn on network_access, but they can't say which origins they contact. Declaring them lets the platform limit an extension's requests to those origins. #9003 added the same allowed_sources list for theme app extensions.

WHAT is this pull request doing?

UI extensions accept a [capabilities.network_access] table with an allowed_sources list, in the same shape theme app extensions use:

[[extensions]]
type = "ui_extension"
name = "My checkout extension"
handle = "my-checkout-extension"

[[extensions.targeting]]
target = "purchase.checkout.block.render"
module = "./src/Checkout.jsx"

[extensions.capabilities.network_access]
allowed_sources = ["https://api.example.com", "https://*.cdn.example.com"]

• The table turns network access on, limited to those origins. TOML can't hold both network_access = true and a network_access table, so the table can't mean anything else. network_access = true / false work as before.
• Shared rules. The allowed_sources parsing and normalization from Let theme app extensions declare the network origins they contact #9003 moved to models/extensions/network-access.ts, and both specs use it, so validation, normalization (trim, lowercase, drop a trailing / and :443, dedupe, at most 20) and error messages are identical. Theme behavior is unchanged.
• Table errors. A table without allowed_sources gets the same "required" error as theme extensions. Other keys are rejected and named (unexpected keys: enabled. Only allowed_sources should be provided.). Every invalid entry is listed in one error. The UI schema branches on the value's type instead of using a zod union, so the loader reports the table's errors rather than Expected boolean, received object.
• Readers treat the table as true. The app dev payload's networkAccess is true for a table. Deploy config already passes capabilities through, so the normalized table is what gets deployed.

TOML	app dev networkAccess	Sent on deploy
No network_access	false	Nothing (unchanged)
network_access = true / false	true / false	network_access: true / false (unchanged)
allowed_sources = [...]	true	network_access: {allowed_sources: [...]} (normalized)
allowed_sources = []	true	network_access: {allowed_sources: []}

How to manually test your changes?

1. Add the TOML above to a UI extension and run shopify app build. The config loads.
2. Change an entry to http://api.example.com or add enabled = true to the table. Loading fails with errors that name the bad entry or key.
3. Run shopify app dev. The extension's dev payload reports networkAccess: true.
4. Replace the table with network_access = true. Behavior matches main.

Post-release steps

Document [extensions.capabilities.network_access] allowed_sources for UI extensions once the server-side gate opens.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.