dsh-laya

Configuration

- insert:
    - id: laya
      name: 'dsh-laya'
      config:
        sidecarUrl: 'http://127.0.0.1:8787'
        requestTimeoutMs: 120000
        lifecycle: never      # 'attach' to log a reachability check,
                              # 'spawn' to start the sidecar yourself
        spawnCommand: null    # required by 'spawn', e.g. ['laya-mcp', 'serve']
        spawnTimeoutMs: 120000
        logLevel: info

lifecycle decides what happens when nothing is answering at sidecarUrl:

never	Start nothing; assume something else manages the sidecar. The default.
attach	Also check /health once at load and log what it found — useful when the harness and the sidecar race at startup.
spawn	Also run spawnCommand if nothing answers, then wait for it to come up.

spawn exists because the alternative was worse. The plugin still installs nothing and downloads nothing — a tool that ran pip install and then fetched a 650 MB checkpoint behind your back would be hostile, and that has not changed. But launching a sidecar you already installed is a different act, and without it every session began by starting a Python process in a terminal by hand, and began failing again every time that process went away.

Two rules make it safe to leave on:

• A sidecar that is already answering is attached to and never touched, so two harness sessions cannot put two models on one port.
• A sidecar this plugin started is stopped when the plugin unmounts; one it did not start is left exactly as it was found.

There is still no option that installs anything or fetches a model, and spawnCommand has no default: this plugin will not guess at an interpreter.

Pointing sidecarUrl somewhere that is not loopback is allowed and warns once at startup, naming the destination: that is the moment the privacy story changes, and it should not be discoverable only by reading a config file.