Frequently asked questions

The `wl` CLI renders and writes files for Claude, Codex and Gemini. A GitHub Copilot renderer exists and is available through the registry’s render preview; the CLI does not write Copilot files yet.

A workspace is the desired state for a repo, folder or service, written into a project directory. A home profile is a workspace target whose target root is home: it writes into your home directory, only inside the home allowlist, and records every file it owns in a home manifest.

No. It writes only files it owns or may create. An unowned file at a path it wants is a conflict, left alone unless you choose --adopt, which backs it up first. `wl keep-local` keeps your edit to an owned file as a user override.

No. Every rendered file has a trust category, and executable, network-bearing and authority-expanding files need a recorded approval before they are written. Otherwise they are reported, not written.

Run `wl sync --check` in the pipeline. It compares files on disk with the bound workspace’s current revision and exits non-zero when anything drifted.

Outcome events for pull, sync, diff and push, sent to your own registry: the operation, result, provider, package name and version, duration, error category, drift counts, source and platform, and no file contents. It is on by default; `wl telemetry opt-out` or WL_TELEMETRY=false turns it off.

No. A review is advisory and never approves or blocks a package version. The secret scan is the gate: the registry refuses a version whose content contains a credential.

With the installer from the public work-loom-releases repository, pinned to a CLI release (VERSION=cli-v0.1.0-test2, a test build). It downloads a prebuilt wl binary for macOS, Linux or Windows, checks its checksum and installs it to ~/.workloom/bin. The CLI is not on npm.

Yes, built with Tauri: it binds a folder to a workspace and shows status, diffs, sync and overrides. The only published build is a test release, desktop-v0.1.0-test3.