IT prerequisites

This page lists what IT must allow for users to install and run Nexus. Workstation baseline applies to every deployment. Outbound network and identity apply only when the corresponding backend connections are enabled. Engineering software access applies for every CAD or CAE integration in use. See Architecture overview for the connection model.

​

Workstation baseline

Required for every deployment.

​

Code signing

The installer and all bundled binaries are signed with an Authenticode certificate. IT teams that enforce execution policy through AppLocker, Windows Defender Application Control, or signature-based EDR rules should permit binaries signed by the Cosmon publisher certificate.

​

Process spawning

The desktop application is the parent process. While Nexus is running, it spawns and supervises two child processes: the agent runtime and the tool server. EDR and behavior-monitoring tools (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, Carbon Black, and equivalents) may flag this parent-child pattern. The Cosmon parent process should be allowlisted to spawn its child binaries. The bundled runtime also includes a Python interpreter that ships inside the application package; allowlist it as part of the Cosmon process tree.

​

Local network — loopback port binding

The three processes communicate over 127.0.0.1 (loopback) on randomly assigned ports. Windows Defender Firewall, or any host-based firewall, must permit the Cosmon binaries to bind loopback ports. No ports are exposed on external network interfaces, and the application accepts no inbound connections from the network.

​

File system

The application reads and writes its data under the user’s app data directory. Standard user permissions are sufficient — administrator privileges are not required to install or run Nexus.

​

Outbound network

Required only when one or more backend connections are enabled (see Architecture overview). A fully airgapped deployment — machine-locked license, BYOK to an internal endpoint, telemetry off, traces off — requires no outbound network rules.

​

Egress rules per connection

For shared-tenant deployments, the only Cosmon domain ever contacted is api.cosmon.com. For single-tenant or customer-hosted backends, that destination is replaced by the customer-specific URL. In BYOK mode, IT must permit egress to the customer-chosen LLM endpoint. Cosmon does not place any other constraint on that endpoint.

​

Proxy

Nexus reads proxy configuration from the standard environment variables. There is no application-specific proxy configuration to set inside Nexus. If the proxy presents a custom root CA (TLS inspection), see TLS inspection and corporate certificate trust — the CA must be installed in the OS certificate store, not configured inside Nexus.

​

TLS inspection and corporate certificate trust

Nexus trusts the operating system’s certificate store. If the corporate environment performs TLS inspection through a proxy with a custom root CA, that CA must be installed in the Windows certificate store. Once installed at the OS level, no Cosmon-specific configuration is needed.

​

Streaming connections (SSE)

For shared-tenant and customer-hosted deployments, Nexus opens a Server-Sent Events (SSE) stream to the backend so that model output appears incrementally as the agent runs. Some VPN and forward-proxy products (Netskope, Zscaler, and similar) buffer or aggregate streamed responses by default, which causes Nexus to receive the full response only after the model has finished rather than token by token. If a VPN or inspecting proxy is in the egress path, SSE responses must be passed through without buffering — no man-in-the-middle aggregation of text/event-stream bodies. The built-in network diagnostics (see Diagnostics) verifies this end-to-end.

​

Identity

Required only when authorization is set to a named license (SSO) or a floating license. Skip this section if all users are activated with machine-locked licenses.

​

OAuth sign-in flow

When a user signs in, the desktop application opens the user’s default browser to an authorization endpoint hosted by the Cosmon backend. After the user authenticates, the browser redirects to a localhost callback URL that the desktop application listens on for the duration of the sign-in.

​

Federated SSO

For enterprise customers using a single-tenant Cosmon backend, the backend can be federated to the customer’s identity provider (Okta, Microsoft Entra ID, Google Workspace, etc.) over SAML 2.0 or OIDC. The customer’s SSO admin provisions the Cosmon backend as a relying party or service provider in the IdP. This federation is configured once during deployment with Cosmon and is not a per-workstation concern.

​

Engineering software access

Required for every deployment that uses CAD or CAE integrations. The tool server drives the engineering software installed on the same machine. To do that, IT must permit two patterns. Spawning third-party CAD/CAE processes. The tool server starts the engineering application’s executable (or attaches to an already-running instance). EDR will see the Cosmon tool server spawning a third-party binary like abaqus.exe, SLDWORKS.exe, or ANSYS.exe. The tool server should be allowlisted to spawn these binaries. Loading a Cosmon-shipped plugin inside the host application. Each integration ships with a plugin — a DLL, add-in, or script extension depending on the host — that loads into the CAD/CAE process. The plugin binds a loopback port and receives commands from the tool server. Both the plugin loading into the host process and the loopback bind must be permitted. Runtime-generated automation executables. Some integrations rely on automation executables that the host application generates at runtime (for example, SolidWorks COM automation helpers). These appear in a per-user folder and are not signed by the host vendor, so antivirus and EDR may quarantine them on creation or first execution. The folder used for these helpers should be added to the AV/EDR exclusion list, or the Cosmon tool server permitted to launch unsigned children of that folder.

​

Diagnostics

Nexus ships a network diagnostics panel under Settings → Network. IT can use it to verify, from the user’s machine, that:

• DNS resolves and TLS handshakes succeed against every required egress destination (auth, LLM routing, telemetry, traces).
• Streaming responses (SSE) arrive token by token rather than buffered into a single late response — the test that catches VPN/proxy buffering described in Streaming connections (SSE).
• Loopback ports between the desktop application, agent runtime, and tool server bind without firewall interference.

If a deployment misbehaves in a way that suggests network policy (timeouts, late responses, sign-in callbacks not arriving), running this panel on the affected machine is the recommended first step before opening a support ticket.