\\.\pipe\claude-bridge · Win32/WDAG boundary ·
companion to cowork.exponential-systems.net · 2026-02
On 2026-02-28 (session c672a4f0), a pipe audit of the Windows host found
\\.\pipe\claude-bridge already present and running. This pipe was not installed
by the session or any action taken during it. The discovery occurred during an investigation
into what was controlling Windows Defender Application Guard (WDAG) on the machine.
The session was operating from inside a WDAG container — a fact not known until
WDAGUtilityAccount was confirmed as the active user account mid-session.
Every probe, every compile, every GitHub push had been performed from inside the
isolated VM. The claude-bridge pipe was found running in that environment:
it was already deployed inside the container.
\\.\pipe\claude-bridge was present and active before any action was taken.
It was not installed as part of the Claude Desktop application visible to the user.
Its presence inside a WDAG container indicates it was deployed as part of the container
image or provisioned through the VM configuration.
During the investigation, wdag_launch.exe was built to programmatically
open URLs in Application Guard using the COM API
(CLSID_IsolatedAppLauncher). When the tool was run from inside the
container, it succeeded — launching a further nested Application Guard session.
This established that CoCreateInstance(CLSID_IsolatedAppLauncher)
is callable from inside WDAG and produces a real nested Hyper-V partition,
not a stub.
hvsimgr.exe, hvsics.exe, hvsirpcd.exe)
is the container's own copy — not the host's processes. Reverse engineering
performed against these binaries was reverse engineering the container's view
of its own Hyper-V stack. The nested WDAG launch was a third layer:
host → container → nested container.
Reverse engineering of the bridge established the following capabilities, reconstructed from binary analysis of the observed implementation:
| Capability | Mechanism | Cross-boundary? |
|---|---|---|
| UIAutomation | Win32 UIA_* COM interfaces | Yes — reaches host window tree from container |
| Message injection | SendMessage / PostMessage P/Invoke | Yes — targets host window handles |
| Isolated desktop management | CreateDesktop / SwitchDesktop | Host-side |
| COM launch into WDAG | CLSID_IsolatedAppLauncher | Host → container spawn |
| HvSocket transport | VMBus socket (wshhyperv.dll) | Yes — VMBus channel between host and guest |
| WDAGBridge RPC | IHvsiEidLrpcEp001, HvsiMgrRdpRpc_* | Yes — host/container RPC channel |
Following the reverse engineering, Genesis.Phantom was built as a
clean-room reconstruction of the observed bridge — the same IPC contract, the same
dispatch pattern, the same HvSocket transport, with the surveillance and
injection P/Invoke surface replaced by a governed typed action schema.
The reconstruction produced the following assemblies, which reside on the development machine and have not been committed to the public monorepo:
Genesis.Phantom.Contracts — interface definitions, wire typesGenesis.Phantom.Client — managed client for the bridge pipeGenesis.Phantom.Execution — action dispatch and result handlingGenesis.Phantom.Win32Bridge — Win32 P/Invoke surface and COM interop
A file (win32-bridge.zip) was submitted for analysis and compared
against the canonical Phantom package (session 06a5ab87, 2026-09-03). The comparison
found it to be a surgical derivative of Phantom — not an independent implementation:
deploy-bridge.ps1,
Win32Methods.cs, MessageInjector.cs,
UIAutomationHelper.cs, IsolatedDesktop.cs, app.manifestwin32-client.js,
Program.cs, Win32Bridge.csprojWDAGBridge.cs, WDAGAgent.cs,
WDAGAgent.csproj, README.mdThe excised files are precisely those that implement the cross-VM-boundary capability: the VMBus socket transport and the WDAG agent. The retained files implement the host-side Win32 surface. The derivative was Phantom with the WDAG investigation capability removed.
The WDAG bridge operates at the Win32/Hyper-V boundary, independently of the Cowork VM (which operates at the Linux guest/virtiofs boundary) and the browser extension (which operates at the browser network layer). It is a third distinct interception surface, with its own transport (HvSocket over VMBus), its own authentication model, and cross-boundary reach that the other two surfaces do not have. It is not documented in the Cowork VM architecture or the browser extension analysis.
Genesis.Phantom.Contracts is a dependency of
Genesis.Attention.Contracts, which provides the desktop observation
layer for the Genesis attention runtime. The attention system uses Phantom's
Win32 capability surface — UIAutomation, window enumeration, isolated desktop
management — to observe what is happening at the Windows desktop boundary.
The WDAG investigation tooling became the infrastructure for a governed
desktop attention system.