Support question: scoped filesystem and loopback access for a fixed-purpose Windows Node command

We are reviewing an integration before deployment. Does Windows Companion 2026.7.1, SourceLink commit 4206611f2b2e47cd575e1c8aa94e3e7708f6dd96, provide an existing supported way to scope MXC filesystem/network permissions to a fixed-purpose command or agent, without broadening the Windows node's global sandbox policy?

The Gateway is 2026.8.2. We have statically reviewed the installed Companion sources using matching DLL/PDB document checksums. We have not executed a reproduction, an MXC probe, or the application integration, so this is a capability/architecture question rather than a confirmed runtime bug.

The integration would expose exactly four read-only SketchUp operations: health, capabilities, model summary, and selection. Model-facing arguments are empty objects; selection options are fixed internally. The underlying immutable CLI needs read access to one explicitly pinned session's discovery/token files, write access to its dedicated workspace and audit receipts, and TCP access to one pinned 127.0.0.1 port. Token contents would never be model arguments or command-line arguments.

Findings at the installed Windows commit:

• ExecApprovalV2InputValidator.cs rejects non-empty custom env before execution.
• MxcPolicyBuilder.cs derives filesystem and network policy from node settings.
• MxcConfigBuilder.cs adds per-run scratch write access and, where permitted, cwd read access. The reviewed network emission uses internetClient and a default allow/block setting; we did not find a mapping for one loopback port.
• The FAQ distinguishes Gateway agent sandbox policy from Windows MXC and also documents host-dependent child-executable limitations. Its referenced Gateway verification version differs from ours, so we are not assuming full Gateway compatibility from that document.

Could you clarify:

1. Is there an existing Windows-node mechanism for command/agent-scoped filesystem grants and a single loopback destination, while leaving global sandbox settings unchanged? If so, which configuration/API and source or tests establish enforcement, lifecycle, and removal of only that scope?
2. Can this version support a fixed native launcher that creates a replacement environment for a fixed Node child inside the same enforced sandbox, given the non-empty system.run.env restriction? Is there documented backend support and a fail-closed way to establish parent/child containment? We are not proposing a shell wrapper, host fallback, or a broker outside the sandbox.
3. If no such mechanism exists in this version, please confirm that limitation. If a later release supports it, a specific release/commit and validation reference would help us evaluate it separately; this inquiry is not authorization to upgrade or relax policy.

We want to preserve both local exec approval and containment. A general node.exe allowlist, global network enablement, uncontained fallback, or a prompt-only four-tool restriction would not meet the integration boundary. No production changes or application/model operations have been performed for this inquiry.

Start with ExecApprovalV2InputValidator.cs, MxcPolicyBuilder.cs, and MxcConfigBuilder.cs at commit 4206611f2b2e47cd575e1c8aa94e3e7708f6dd96, then review the linked execution FAQ. Determine whether this version documents or implements command-scoped filesystem grants, a single loopback destination, and fail-closed parent/child containment without changing global policy; done requires a source or test-backed confirmation of support or limitation.