omp packages

vmark-omp-extension0.1.1

Drive VMark from omp/pi over its localhost WebSocket bridge — nine tools, no MCP sidecar, no client config.

blackplume Published 27 days ago ISC ~343 downloads/mo

Built for omp

The author tagged this package oh-my-pi.

Did it work for you?

Result

One report per person. A new report replaces your old one.

Reports 0

No reports yet.

Readme

vmark-omp-extension

Drive VMark from omp (or any pi host) as nine ordinary tools — over VMark's localhost WebSocket bridge, with no MCP sidecar, no client config, and no VMARK_MCP_TOKEN to plant.

Install

npm install -g vmark-omp-extension

Then point your agent host at the installed directory, or copy the single bundled file into the host's extension directory:

cp "$(npm root -g)/vmark-omp-extension/dist/extension.js" ~/.omp/agent/extensions/vmark-omp.js

Restart the host. Nine vmark_* tools appear. Nothing else is required — VMark must simply be running with Settings → Integrations → MCP Server on, which is its default.

What you get

Tool Approval Actions
vmark_session read get_state
vmark_workspace write new open open_workspace save save_as close switch_tab focus_window
vmark_document write read write transform
vmark_workflow write apply_patch validate
vmark_selection write get set
vmark_browser exec 12 actions on the embedded browser
vmark_browser_read read 8 read-only actions
vmark_coherence read status edges claims contexts
vmark_coherence_resolve write resolve

Forty-one actions in total. Documents round-trip through read → reason → write with an optimistic-concurrency revision: a write carrying a stale revision is refused with a machine-readable STALE payload that includes the current revision, so an agent re-reads and retries instead of clobbering.

Take expected_revision from a READ, never from a write's response

A successful document.write reports a revision that is not reliably the document's current revision. Measured against VMark 0.9.81, the behaviour is NOT deterministic:

  • in one session (a freshly created, sole, active tab, 6 iterations) the value a write returned was superseded by the time of the next read 6 of 6 times, and a second write chained onto it was refused STALE 6 of 6 times;
  • in two other sessions — a tab restored by hot exit, and a two-tab test on both the active and the background tab — the write's value matched the following read every time.

What is ruled OUT: it is not a timing window. Reading 5 s later returned the same revision the first read had, so the value was superseded immediately and then stayed put.

What is NOT known: why it varies. A plausible candidate is the revision bump being delegated to the editor's transaction in the active-editor path (inside writeContent), which would make the answer depend on whether the editor is bound to the target tab and on when its re-serialization lands — but a test of that branch did NOT reproduce the failure, so treat it as a hypothesis, not a diagnosis.

The operational rule is the same either way, because the failure mode is a wasted round trip and a confusing error, not data loss (STALE fails closed): take expected_revision from document.read, selection.get, or session.get_state — those three agreed with each other on every check — and re-read before a second write rather than reusing a write's response.

This is VMark's own revision bookkeeping, passed through unchanged (the same behaviour applies to VMark's bundled MCP sidecar), not something this extension adds or hides.

How it works

The extension opens a WebSocket to ws://127.0.0.1:<port>, authenticating with the token VMark publishes in its mcp-port file. VMark's Rust bridge dispatches on the request's type string and does not care who the caller is, so a plain WebSocket client is capability-equivalent to the official sidecar.

Two details make it survive real use:

  • The port and token are re-read on every connection attempt. VMark republishes both on each launch, so a restart is picked up without restarting the agent.
  • A watchdog reconnects while the bridge is down. The bridge's own retry loop has a finite budget, and once spent nothing revives it from this side — so a disconnected bridge is nudged back up on an interval instead of staying dead until the host restarts.

Windows and Linux are fully supported except the embedded-browser actions, which are macOS-only in VMark and answer UNSUPPORTED_PLATFORM elsewhere.

Provenance

The nine tools are not reimplemented. The tool layer is vendored byte-for-byte from VMark and driven through VMark's own server object, so the tool names, descriptions, argument guards and vmark.* request vocabulary are the shipped ones.

  • vendor/VENDOR.json records the source commit and a SHA-256 per file.
  • vendor/mcp/LICENSE carries the upstream licence, itself hashed.
  • dist/extension.js is a single self-contained file; ws and zod are inlined, so a consumer installs no runtime dependencies.
  • The parameter schemas are the one part that is transcribed rather than vendored — a real-zod object cannot be handed to a host that only accepts its own Zod-compatible builder — and the transcription is checked against the vendored source by rendering both to JSON Schema and comparing.

License

ISC © 2026 Xiaolai Li. See LICENSE; the vendored VMark code is the same licence, reproduced in vendor/mcp/LICENSE.