Source control

Your organization’s Home repository

Every organization owns a Home repository at <org>/home. Imported projects and native Vex work meet there as one shared history. Virtual repositories can expose a stable subtree without making a second physical repository.

Clone and access

Use the Vex-native clone path for a local checkout with Vex history and change workflows.

vex clone <org>/<repo>
cd <repo>
vex status

Use vex clone <org>/<repo> --fs virtual only when a local virtual filesystem is available. A normal checkout remains the supported fallback. Repository access tokens allow scoped automation; browser downloads and API tokens have their own authorization boundaries.

Submit changes, then land them

Vex tracks JJ changes separately from named bookmarks. Start work above a target, describe it, submit it, and request landing only when it is ready.

vex new main
vex describe -m "feat: add the change"
vex submit --target main
vex change show #42
vex land #42

vex sync fetches the target and reconciles submitted changes with server state. vex land #N retains CI, approval, queue-order, and target-freshness gates for the submitted-together closure.

Key repository surfaces

• Browse trees, files, history, branches, changes, checks, and queue state in the web app.
• Create repository access tokens for scoped automation.
• Use virtual repositories when a project needs a rooted view of a monorepo path.
• Connect external Git sources with remote Git sync.
• Run GitHub-compatible workflows from .vex/workflows; see CI.

Virtual working-copy capability model

The browser shows server-safe repository information; it cannot open a local daemon socket. Inspect the actual host capability with the CLI or desktop application.

vex daemon status --format json
vex daemon capabilities --format json

The local daemon and its mount are host-specific. When the capability is unavailable, use a normal checkout and keep the same Vex source-control workflow.