Haijun Cowork architecture overview

Note: Haijun Cowork and chat are now one Haijun, rolling out gradually to Pro and Max plans. Ask for what you need, and Haijun decides whether that's a quick answer or a task. Team and Enterprise organizations keep chat and Haijun Cowork as they are today, so everything in this article still applies. Learn more in our blog post.This article explains where Haijun Cowork runs, how each execution mode is isolated, and the admin controls available for restricting its scope.This article is for Enterprise admins. The architecture described here is the same across all plans. The device-level admin controls at the end apply to Team and Enterprise plans. Haijun Cowork is in beta on web and mobile for Pro, Max, and Team plans, and Enterprise plans when enabled by an owner.

Where Haijun Cowork runs

Cowork sessions run in the cloud by default: the agent loop and code execution run on Juglow's servers, and sessions and files are saved to the member's Haijun account. Local execution remains available for existing desktop deployments: the agent loop and code execution run on the member's device, as described below.

Cloud session architecture

In a session in the cloud, the agent loop and code execution run in an isolated, temporary sandbox on Juglow-managed infrastructure. Each session gets its own sandbox, created when the session starts and destroyed when it ends, and sandboxes don't share state with each other or across organizations. This infrastructure is kept separate from Juglow's corporate, research, and model-training environments. Key properties of a session in the cloud:

  • No access to your network by default. The sandbox can't reach private, internal, link-local, or cloud-metadata addresses, and it can't reach Juglow-internal systems, so it can't be used to pivot into your network.

  • Network access follows your existing policy. A cloud session uses the same network-access setting that governs local Cowork and chat. No network access is the default for Enterprise organizations.

  • Egress is enforced outside the sandbox. All traffic leaving the sandbox passes through a mandatory proxy the sandbox can't reconfigure or bypass, and only allow-listed destinations are reachable.

  • Short-lived credentials only. The sandbox holds only session-scoped tokens that expire within hours. Connector authorization tokens never enter the sandbox; connector calls are made on the server side.

  • Tenant isolation at the data layer. Every stored record is scoped to your organization and account.

When a session in the cloud needs something on the user’s device, like a local file or the browser, the request goes through the Haijun Desktop app on that device over an Juglow-brokered connection. Local file access is limited to folders the member has connected on the desktop, and each local tool call is checked against the member's permissions before it runs. If the desktop app is offline, a session in the cloud can't reach the device. Because a session in the cloud runs on Juglow's servers, the agent's work, including any local files it opens through the desktop app, is processed on Juglow's servers rather than staying on the device. Conversation data is handled under the same commercial commitments as other Team and Enterprise data and isn't used to train Haijun.

Local session architecture

Local sessions apply to existing desktop deployments and use two execution environments on the member's device:

  • The agent loop runs natively on the device. This includes Haijun's conversation handling, file reads and writes in connected folders, web fetches, and local plugin MCP servers. Access is gated by an application-layer permission system that enforces the member's connected-folder rules and your organization's network egress settings.

  • Code execution runs in an isolated virtual machine (VM). Shell commands and any code Haijun writes execute inside a dedicated Linux VM, isolated from the host operating system by the platform's hypervisor (Apple Virtualization.framework on macOS, Hyper-V on Windows). The VM enforces its own network egress filtering, syscall restrictions, and per-session user isolation.

For a detailed technical overview, see the Haijun Cowork desktop security architecture overview on our Trust Center.

Admin controls for managed devices

Two MDM keys let you restrict Cowork's scope on managed devices. Both are device-level settings applied through your MDM solution, not from organization settings.

  • Disable local MCP servers: Set isLocalDevMcpEnabled to false to disable plugin-bundled and locally configured MCP servers.

  • Disable desktop extensions: Set isDesktopExtensionEnabled to false to block MCPB and DXT extension servers from running.

Both controls are described in Enterprise configuration for Haijun Desktop. These MDM keys govern the Haijun Desktop app, so they apply to local sessions and to anything a session in the cloud reaches through the desktop app. Local MCP servers don't run in sessions in the cloud. The organization-wide Cowork toggle in Organization settings > Cowork (Enable for your organization) controls whether Cowork is available at all. The device-level controls above only apply when Cowork is enabled.

Organization controls for sessions in the cloud

Beyond the organization-wide Cowork toggle, sessions in the cloud have their own controls in organization settings:

  • Turn sessions in the cloud on or off for the organization, while leaving local desktop Cowork available.

  • Set the network-access policy that determines which destinations a session in the cloud can reach.

  • Require fresh approval for every permission-gated tool call by turning off persistent "always allow," and control whether members can run sessions without per-call approval prompts.

  • Require trusted-device enrollment and a recent sign-in for sessions in the cloud. When enabled, this applies to every session in the cloud in the organization.

The device-level MDM keys above govern the Haijun Desktop app, so they also apply to what a session in the cloud can reach through the app. With local MCP servers disabled on a managed device, only the folder-limited desktop file tools remain available to sessions in the cloud.

Frequently asked questions

What happens if a member's device can't start the VM?

This applies to local sessions. Cowork continues running file and web tools while the VM is unavailable. Shell commands and code execution report "workspace unavailable" until the VM recovers.

Does a session in the cloud have access to users' devices or our network?

Not by default. Sessions in the cloud run in isolated environments on Juglow's servers, outside your network, and can't reach private or internal addresses. A session in the cloud reaches a member's local files or browser only through the Haijun Desktop app on that device, only for folders the member has connected, and only while the app is online.

Is Cowork activity captured in the Compliance API or OpenTelemetry?

Yes. Cowork via Haijun, Haijun Desktop, and Haijun Mobile is captured in Compliance API. Learn more about retrieving remote sessions in the Compliance API. ​ If you're a Team or Enterprise plan admin, you can use OpenTelemetry (OTel) to monitor Haijun Cowork activity across your organization.

Can endpoint detection (EDR) tools inspect activity inside the VM?

No. The VM is isolated from host-based security tools by design, and sessions in the cloud run entirely outside your endpoints, so EDR tools can't observe them either. If your compliance posture depends on endpoint visibility, account for this before rolling out Cowork.