SkillWire local verification executes repository-defined commands on the host machine as the current user. The MVP local backend is NOT a sandbox and provides NO isolation boundary.

A repository command may:

• read or modify any file available to the current user;
• start child processes;
• access the network;
• connect to local or remote services;
• run package-manager lifecycle scripts;
• consume credentials or other host resources that the process can discover independently.

SkillWire's controls—structured argument vectors, an explicit working directory, a filtered inherited environment, cancellation, timeout, bounded output-pipe waiting, output capture, declared effects, and approval prompts—improve visibility and reduce accidental execution mistakes. They do not make untrusted repository code safe.

The local backend bounds the time os/exec waits for stdout/stderr copy pipes after cancellation or direct-child exit. This prevents descendants that inherited those handles from hanging verification indefinitely. It is not process-tree isolation: a descendant process may continue running after the direct command is cancelled.

Do not verify code you would not otherwise run on your machine.

These operations do not execute repository-defined commands:

skillwire init
skillwire inspect
skillwire refresh
skillwire components
skillwire resolve
skillwire explain
skillwire profile ...
skillwire export
skillwire serve --mcp
skillwire check

skillwire check is intentionally non-executing by default so it can run in ordinary pull-request CI.

Execution occurs only through explicit verification paths such as:

skillwire verify ...
skillwire override verify ...
skillwire check --verify
skillwire benchmark --execute ...

deps.install can access package registries, write dependency directories and caches, modify lockfiles depending on tool behavior, and run package lifecycle hooks. Noninteractive dependency verification requires --allow-install in addition to execution approval.

A command resolved for environment=ci may rely on runner variables, secrets, generated files, services, or prior workflow steps that do not exist on the local machine. Verification defaults to local capabilities. Noninteractive CI-scoped verification requires --allow-ci-context.

A CI-scoped failure must not automatically be interpreted as a bad resolution; missing runner context may be the cause.

SkillWire stores executable commands as:

{
  "executable": "uv",
  "arguments": ["run", "pytest"]
}

The local backend invokes this vector directly with os/exec; it does not pass normal commands through a shell. Repository text containing compound shell constructs is not converted into an executable SkillWire candidate.

This reduces shell-injection surface but does not make the invoked executable trustworthy.

Persisted working directories are repository-relative and use forward-slash semantics on every host. Validation rejects absolute POSIX paths, Windows drive paths, backslashes, and traversal above the repository root even when a lock file is reviewed on a different operating system.

The local backend resolves both the repository root and selected working directory through filesystem symlinks, then re-checks containment before execution. A repository-relative symlink that resolves outside the repository is rejected.

Captured stdout and stderr are each limited to 1 MiB in memory. Run logs record truncation and total observed byte counts, so a noisy repository command cannot force unbounded output capture growth.

The v0.1 MCP server exposes only read/resolve/explain/status tools. It has no arbitrary command-execution or verification tool.

A future container, namespace, VM, or CI backend may provide stronger containment. No such guarantee applies to LocalBackend. Any future isolation claim must be backend-specific and backed by tests.

Do not open a public issue for an undisclosed vulnerability. Use GitHub private vulnerability reporting for the repository and include:

• affected version or commit;
• reproduction steps;
• expected and observed behavior;
• potential impact;
• suggested mitigation, when available.