psa-systems/vervain-agent
Watch
9
0
Fork
You've already forked vervain-agent
 0
Code Issues Pull requests Projects Releases 7 Packages Wiki Activity Actions

feat(protocol): advertise VNC and MCP capability bits #153

Merged
Claude-Run merged 1 commit from feat/VA-141-vnc-mcp-capability-bits into main 2026-07-28 12:58:11 +02:00
Conversation 0 Commits 1 Files changed 2 +31 -6
Claude-Run commented 2026-07-28 12:53:07 +02:00
Member
Copy link

The agent serves three tunnels nobody can discover: the x11vnc/wayvnc bridge (USAGE_VNC 6), the in-process RFB server (USAGE_VNC_NATIVE 9), and the MCP JSON-RPC tunnel (USAGE_MCP 8). The capability bitfield had no bit covering any of them, so detect_capabilities() advertised TERMINAL | FILES | CONSOLE | AGENT_UPDATE_ZSTD (plus DESKTOP on Linux) and the frontend, which gates its per-device tunnel buttons on that bitmap, hid the buttons for tunnels that work today.

Add Capabilities::VNC (0x400) and Capabilities::MCP (0x800) and set both unconditionally. One VNC bit covers both usage 6 and usage 9: the native RFB server is compiled with no cfg gate and needs no host binary, so some VNC path always answers and the choice is made at tunnel-open. MCP is likewise unconditional; mutating-tools changes the tool surface, not whether the tunnel answers.

The bit-by-bit audit comment above detect_capabilities() gains entries for both bits naming their implementing modules, and the pinned detect_capabilities_matches_wired_subsystems test carries them in both its symbolic and numeric expected values plus explicit contains-assertions.

Capabilities is a hand-synced duplicate of vervain-agent-proto in vervain-server; the mirroring change there is tracked in VS-96 and is required before this is observable, and the frontend gating is tracked in VAPP-90.

#VA-141

The agent serves three tunnels nobody can discover: the x11vnc/wayvnc bridge (USAGE_VNC 6), the in-process RFB server (USAGE_VNC_NATIVE 9), and the MCP JSON-RPC tunnel (USAGE_MCP 8). The capability bitfield had no bit covering any of them, so `detect_capabilities()` advertised TERMINAL | FILES | CONSOLE | AGENT_UPDATE_ZSTD (plus DESKTOP on Linux) and the frontend, which gates its per-device tunnel buttons on that bitmap, hid the buttons for tunnels that work today. Add `Capabilities::VNC` (0x400) and `Capabilities::MCP` (0x800) and set both unconditionally. One VNC bit covers both usage 6 and usage 9: the native RFB server is compiled with no cfg gate and needs no host binary, so some VNC path always answers and the choice is made at tunnel-open. MCP is likewise unconditional; `mutating-tools` changes the tool surface, not whether the tunnel answers. The bit-by-bit audit comment above `detect_capabilities()` gains entries for both bits naming their implementing modules, and the pinned `detect_capabilities_matches_wired_subsystems` test carries them in both its symbolic and numeric expected values plus explicit contains-assertions. `Capabilities` is a hand-synced duplicate of `vervain-agent-proto` in vervain-server; the mirroring change there is tracked in VS-96 and is required before this is observable, and the frontend gating is tracked in VAPP-90. #VA-141
feat(protocol): advertise VNC and MCP capability bits
All checks were successful
Check / fmt + clippy + tests (pull_request) Successful in 4m16s
Details
Create release / Create release from merged PR (pull_request) Has been skipped
Details
316427ad69 
The agent serves three tunnels nobody can discover: the x11vnc/wayvnc bridge (USAGE_VNC 6), the in-process RFB server (USAGE_VNC_NATIVE 9), and the MCP JSON-RPC tunnel (USAGE_MCP 8). The capability bitfield had no bit covering any of them, so `detect_capabilities()` advertised TERMINAL | FILES | CONSOLE | AGENT_UPDATE_ZSTD (plus DESKTOP on Linux) and the frontend, which gates its per-device tunnel buttons on that bitmap, hid the buttons for tunnels that work today.

Add `Capabilities::VNC` (0x400) and `Capabilities::MCP` (0x800) and set both unconditionally. One VNC bit covers both usage 6 and usage 9: the native RFB server is compiled with no cfg gate and needs no host binary, so some VNC path always answers and the choice is made at tunnel-open. MCP is likewise unconditional; `mutating-tools` changes the tool surface, not whether the tunnel answers.

The bit-by-bit audit comment above `detect_capabilities()` gains entries for both bits naming their implementing modules, and the pinned `detect_capabilities_matches_wired_subsystems` test carries them in both its symbolic and numeric expected values plus explicit contains-assertions.

`Capabilities` is a hand-synced duplicate of `vervain-agent-proto` in vervain-server; the mirroring change there is tracked in VS-96 and is required before this is observable, and the frontend gating is tracked in VAPP-90.

#VA-141
Claude-Run deleted branch feat/VA-141-vnc-mcp-capability-bits 2026-07-28 12:58:11 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/vervain-agent!153
No description provided.