Sandbox defaults

External tools launched by the daemon now run inside the weaver-sandbox wrapper around birdcage 0.8.1. Linux namespaces and seccomp-bpf filters are applied automatically; networking is disabled by default; and only a small set of standard library directories are readable to keep dynamically linked executables functioning. Commands must be provided as absolute paths and added to the sandbox allowlist before launch; requests made from multithreaded contexts return a MultiThreaded error rather than panicking the process. The sandbox strips the environment unless specific variables are explicitly whitelisted, so callers should pass configuration via the broker rather than relying on inherited host state.

weaver now exposes explicit lifecycle commands so operators do not need to manage the daemon manually. All three commands share the same helper logic and therefore honour the configuration flags supplied to the CLI, including --config-path and --daemon-socket.

• weaver daemon start verifies that the configured socket is free, spawns the weaverd binary (the path can be overridden via WEAVERD_BIN), and waits for the health snapshot to report ready. The command refuses to start when the socket already accepts connections and prints the runtime directory that now holds the lock, PID, and health files.
• weaver daemon stop reads the PID file, sends SIGTERM, and waits for the runtime artefacts and socket to disappear. If the socket is reachable but the PID file is missing, the command surfaces an error rather than blindly killing a process. Successful stops report the PID that was terminated and confirm the runtime directory was cleaned up.
• weaver daemon status inspects the JSON health snapshot when present, falling back to the PID file and socket reachability. When no runtime artefacts exist the command prints a short reminder that daemon start can be used to launch a new instance.

Lifecycle commands never contact the daemon's JSONL transport. They operate on shared runtime files from weaver-config, so the CLI and daemon use the same directory layout even when the daemon socket is overridden.

When a domain command is issued and the daemon is not running, the CLI automatically attempts to start the daemon rather than failing immediately. The message Waiting for daemon start... appears on stderr while the CLI waits for the daemon to become ready. The timeout for automatic startup is 30 seconds; if the daemon fails to start within this period, the CLI reports the failure and exits.

This behaviour allows operators to run commands without explicitly starting the daemon first:

weaver observe get-definition --uri file:///src/main.rs --position 10:5

If the daemon is not running, it will be started automatically before the command executes. The automatic startup uses the same configuration flags (--config-path, --daemon-socket, etc.) passed to the command.

Errors that prevent connection but are not related to the daemon being offline (such as permission denied or network timeouts) bypass automatic startup and are reported immediately.

When the daemon binary cannot be found, the CLI provides actionable guidance:

$ weaver observe get-definition --symbol main
Waiting for daemon start...
error: failed to spawn weaverd binary 'weaverd'

Valid alternatives:
  - Verify weaverd is installed and in your PATH
  - Set WEAVERD_BIN to the full path to the weaverd binary
  - Inspect runtime artefacts under $XDG_RUNTIME_DIR/weaver

Next command:
  command -v weaverd || echo 'weaverd not found in PATH'

For other startup failures, the CLI suggests checking daemon logs, shows the weaverd.health path when available, and suggests running in the foreground to see startup output:

error: daemon exited before reporting ready (status: Some(1))

Valid alternatives:
  - Check the daemon logs for errors
  - Check health snapshot at $XDG_RUNTIME_DIR/weaver/weaverd.health
  - Run with WEAVER_FOREGROUND=1 to see startup output

Next command:
  WEAVER_FOREGROUND=1 weaver daemon start