Browser and Workstation Requirements

Claira runs inside Nuix Discover in the browser. There is nothing to install on a workstation — no desktop agent, no plug-in, no browser extension. This page is for the IT or desktop engineering team that has to make Claira work on managed machines, and for the Claira administrator who needs to tell them what to allow.

If your Discover environment is hosted by Nuix, the first two sections are the whole requirement. If Discover runs on your own infrastructure, read the on-premises section as well.

Supported browsers

Use the current stable release of either:

• Google Chrome
• Microsoft Edge (Chromium)

Keep workstations on the vendor's stable update channel. Claira is a web application and is tested against current stable browsers.

Claira also works in Mozilla Firefox today.

Network access

Claira needs one outbound rule:

• HTTPS over TCP 443 to *.claira.to

If your egress policy does not allow wildcard destinations, allow at minimum the regional host your tenant uses — for example https://nuix-ca.claira.to for the Canadian deployment or https://nuix-au.claira.to for the Australian one. This is the same address a portal administrator entered when setting up the UI Extension.

Nothing else is required: no inbound rules, no additional ports, and no changes to workstation software.

If Discover is hosted by Nuix

Nothing special is needed. Both Claira and your Discover Portal-API are public addresses, so the browser treats the traffic between them as ordinary public-to-public requests.

None of the on-premises considerations below apply to you. Current stable Chrome or Edge, plus the outbound rule above, is the complete requirement.

If Discover runs on-premises

Claira is a UI extension: it loads inside the Discover page, and it makes a direct call from the reviewer's browser to your Discover Portal-API to retrieve document text and natives. That call goes from the reviewer's workstation to your own servers, so it has to be permitted at two separate layers.

Two things must be true.

1. Your Portal-API must allow the Claira origin (CORS)

Because the request comes from a page served by Claira and goes to a host in your environment, the browser treats it as cross-origin and requires your Portal-API web tier to say it is allowed.

On both the preflight OPTIONS request and the POST that follows, the Portal-API must return:

Access-Control-Allow-Origin: <the Claira origin>
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Allow-Methods: POST, OPTIONS

The OPTIONS request must return a 2xx status. The Claira origin is the address configured for your UI Extension, such as https://nuix-ca.claira.to.

2. The browser must allow the request into your internal network

This is a newer restriction in Chromium browsers called Local Network Access, and it is separate from CORS. It applies when a page served from a public address tries to reach a private or internal address.

That is exactly the shape of an on-premises deployment: Claira is served from a public address, while your Discover Portal-API resolves to an address inside your network. Chrome and Edge block that request before your Portal-API ever sees it.

The console error usually reads:

has been blocked by CORS policy: Permission was denied for this document to access the local address space

Firefox does not enforce Local Network Access yet. "It works in Firefox but fails in Chrome and Edge" is the signature of this specific restriction — it is not a fault in Claira or in your Portal-API configuration.

The remedies below are listed in order of preference.

Recommended: serve Claira from an internal hostname

Put an internal reverse proxy in front of Claira — an internal hostname that forwards over 443 to your Claira regional host. The browser then sees Claira on a private-network address, so the public-to-private transition never happens at all. Requests from a local address to another local address are not restricted.

This is the most durable option:

• No browser policy is needed on any workstation.
• It survives browser updates and future changes to the restriction.
• It is one change in your infrastructure rather than a fleet-wide policy rollout.

Ask Nuix to delegate the permission on the extension frame

This is the architecturally correct fix. The embedding Discover page needs to grant the permission to the UI extension frame it loads, using allow="local-network-access" on that frame.

Only Nuix can make this change, since the page doing the embedding is theirs. It is worth raising with them: the same change benefits any on-premises Discover customer using any UI extension, not only Claira.

Browser policy, as a last resort

Chrome and Edge both expose Group Policy settings for this, deployable through Group Policy or Microsoft Intune. This option is workable but is the easiest of the three to get wrong.

Two policies are needed, together:

The second policy takes the Discover host — the address in the browser's address bar — not the Claira host.

Confirm the minimum browser versions against what is actually deployed on your fleet before you rely on this. Microsoft documents the frame-delegation policy as arriving with Edge 146 Stable.

Temporary opt-out, for testing only

LocalNetworkAccessRestrictionsTemporaryOptOut disables the restriction and is useful for confirming a diagnosis quickly.

Related documentation

• Setting Up Claira — the portal-level UI Extension install, including the Claira app URL.
• Checking Installation — confirming Claira is active on a case.
• Privacy and Security — deployment regions and data handling.
• Microsoft: Local Network Access in Microsoft Edge.
• MDN: Local network access.

Need help? Contact us at support@claira.to.