Jon Shapiro 92697edb7c fix(venice): add compat settings to prevent HTTP 400 errors

Venice's API doesn't support certain OpenAI-compatible parameters that
Clawdbot sends by default:

- `store`: Venice returns HTTP 400 with no body when this is present
- `developer` role: Not supported by Venice's API

This adds VENICE_COMPAT settings (supportsStore: false,
supportsDeveloperRole: false) to all Venice model definitions, both
from the static catalog and dynamically discovered models.

Fixes issues reported in PR #1666 where users experienced silent
failures (HTTP 400, no body) when using Venice models.

Co-authored-by: jonisjongithub <jonisjongithub@users.noreply.github.com>
Co-authored-by: Clawdbot <bot@clawd.bot>

2026-01-26 17:56:01 -08:00

3.0 KiB

Raw Blame History

summary

read_when

CLI reference for `clawdbot node` (headless node host)

Running the headless node host

Pairing a non-macOS node for system.run

`clawdbot node`

Run a headless node host that connects to the Gateway WebSocket and exposes system.run / system.which on this machine.

Why use a node host?

Use a node host when you want agents to run commands on other machines in your network without installing a full macOS companion app there.

Common use cases:

Run commands on remote Linux/Windows boxes (build servers, lab machines, NAS).
Keep exec sandboxed on the gateway, but delegate approved runs to other hosts.
Provide a lightweight, headless execution target for automation or CI nodes.

Execution is still guarded by exec approvals and per‑agent allowlists on the node host, so you can keep command access scoped and explicit.

Browser proxy (zero-config)

Node hosts automatically advertise a browser proxy if browser.enabled is not disabled on the node. This lets the agent use browser automation on that node without extra configuration.

Disable it on the node if needed:

{
  nodeHost: {
    browserProxy: {
      enabled: false
    }
  }
}

Run (foreground)

clawdbot node run --host <gateway-host> --port 18789

Options:

--host <host>: Gateway WebSocket host (default: 127.0.0.1)
--port <port>: Gateway WebSocket port (default: 18789)
--tls: Use TLS for the gateway connection
--tls-fingerprint <sha256>: Expected TLS certificate fingerprint (sha256)
--node-id <id>: Override node id (clears pairing token)
--display-name <name>: Override the node display name

Service (background)

Install a headless node host as a user service.

clawdbot node install --host <gateway-host> --port 18789

Options:

--host <host>: Gateway WebSocket host (default: 127.0.0.1)
--port <port>: Gateway WebSocket port (default: 18789)
--tls: Use TLS for the gateway connection
--tls-fingerprint <sha256>: Expected TLS certificate fingerprint (sha256)
--node-id <id>: Override node id (clears pairing token)
--display-name <name>: Override the node display name
--runtime <runtime>: Service runtime (node or bun)
--force: Reinstall/overwrite if already installed

Manage the service:

clawdbot node status
clawdbot node stop
clawdbot node restart
clawdbot node uninstall

Use clawdbot node run for a foreground node host (no service).

Service commands accept --json for machine-readable output.

Pairing

The first connection creates a pending node pair request on the Gateway. Approve it via:

clawdbot nodes pending
clawdbot nodes approve <requestId>

The node host stores its node id, token, display name, and gateway connection info in ~/.clawdbot/node.json.

Exec approvals

system.run is gated by local exec approvals:

~/.clawdbot/exec-approvals.json
Exec approvals
clawdbot approvals --node <id|name|ip> (edit from the Gateway)

3.0 KiB Raw Blame History Unescape Escape

clawdbot node