Bring selected repositories into one working Home.

Vex gives separate physical repositories a shared Home checkout, then uses stacked Changes and Jujutsu to coordinate reviewable work inside each component.

Plan a two-repo pilot See evaluation steps

Flat checkout + repository-routed submission · Component-scoped landing

01 / Repository federation

A central Home without a physical-repo migration.

Register repositories under non-overlapping Home paths. Vex records their selected bookmarks in a versioned manifest and resolves one flat working copy for the team. Each path still knows its owning physical repository.

Home creates one working view; it does not copy every repository into one physical store.

Explore repository federation

Repository federationOne Home checkout

webgithub.com/acme/web

apigithub.com/acme/api

workergit.example.com/acme/worker

registered in

Versioned Home manifest

apps/web← web @ main

services/api← api @ main

services/worker← worker @ main

vex clone acme/home resolves

Flat Home checkout

apps/web/
services/api/
services/worker/

Submit edits by path

apps/web → web revisionservices/api → api revisionservices/worker → worker revision

One aggregate Change can show the cross-path submission. Each child revision stays with its owning repository, and landing remains scoped to that component.

Running product

The federation registry keeps Home and jj separately addressable while making their relationship and external GitHub identity explicit.

This screen proves registered federation state, not aggregate cross-repository landing.

/vex/repos
Vex organization · 11 Aug 2026

Physical repositories

Each source repository remains durable and owns a distinct path in Home.

Versioned manifest

Home records each repository, its checkout path, and the bookmark or version to resolve.

Flat checkout

vex clone <org>/home resolves the manifest into one Vex and Jujutsu working copy.

Repository routing

Vex groups edited files by owning repository and creates one child revision in each.

What happens when work spans owners

Vex groups Home edits by their owning repository. It creates one public aggregate Change for the cross-path submission and one child revision in each repository, preserving project attribution in Home history. The aggregate is reviewable, while landing stays scoped to each component.

02 / Stacked Changes

Review a chain without turning it into one giant change.

A Vex Change keeps its identity while patchsets evolve. The source graph records its dependencies, so reviewers can follow each piece and Vex can check every required Change before landing within one repository.

Explore stacked Changes

Source graph / dependent changes3 Changes

AChange AAdd timezone columnAccepted
BChange BReturn timezone from APIIn review
CChange CShow timezone in settingsWaiting for B

B depends on A, and C depends on B. Before C can land, Vex checks A, B, and C as one required set while keeping each Change separately reviewable.

Running product

Grouped Changes expose stable positions and status for each member without collapsing the chain into one giant diff.

The shown stacks are scoped to individual repository components.

/vex/changes?view=stack
Vex organization · 11 Aug 2026

Keep work independently reviewable

Each Jujutsu change gets a stable Vex identity and patchset history as its code evolves.

See dependency order in source

The graph records what depends on what without branch-name or PR-target conventions.

Gate the accepted stack

Within one component, Vex checks review, policy, CI, freshness, and required ancestors.

03 / Jujutsu

The graph is infrastructure, not a diagram added later.

Jujutsu is a change-based source-control system. Vex maintains its own fork and hosted backend. That lets repository state, durable Change identity, dependencies, review, and landing policy share one model while Git remains an access path.

This is an architecture claim. We are not claiming the fork is categorically faster or safer than upstream Jujutsu.

Explore Jujutsu in Vex

Local to hosted

The local graph and hosted review share one durable Change identity instead of reconstructing it from a branch later.

This is architecture proof, not a performance comparison with upstream Jujutsu.

Ghostty · vex log + vex change show '#625'
Vex organization · 11 Aug 2026

04 / CLI

One command surface for source, agents, and operations.

Set up supported coding agents, navigate the native change graph, open Dash, capture scrubbed Agent Context, and expose repository-aware MCP tools from the same Vex binary.

Explore the Vex CLI

Vex CLI / command map

›vex setup --with-mcp --with-agent-checkpointsSkills · MCP · Agent Context

›vex log -r '::@' --limit 4Native change graph

›vex dash --infra · vex deploy logs --app my-appServices · deploys · live logs

›vex agent-checkpoints doctorProject-local session capture

›vex mcp initRepository-aware tools for agents

One binary

Stay in the terminal from first setup to production evidence.

Use text commands for automation, open Dash when state becomes spatial, and expose the same repository model to supported coding agents through MCP.

Browse CLI commands Set up agents

05–06 / Provenance and landing

05 / Merge Queue

Validate the trunk candidate, not an approximation.

Put Changes and stacks through one ordered pipeline. Vex builds the exact candidate, records required checks, and reconciles followers whenever the durable queue prefix changes. GitHub-primary targets can admit plain pull requests under their stricter sequential boundary.

Explore the Merge Queue

06 / Agent Transcripts

Keep the agent session with the code it produced.

Capture supported coding-agent sessions, screen known sensitive patterns before upload, and bind the authorized record to the exact Change for review, History, and a bounded handoff.

Explore Agent Transcripts

The smallest compelling evaluation

Two repositories. One Home. One component stack.

A platform or DevEx lead can validate the federation model without moving every repository. Vex assists with registration; your team verifies cross-path source and routing, then validates review and landing inside one component.

Plan a two-repo pilot Join the waitlist

Federate

Read back

Clone <org>/home and verify files plus project-attributed history.

Verify submission routing

Edit one Home path and verify the revision appears in its owning repository.

Stack

Create, review, and preview landing for two dependent Changes inside one component.

Excluded from success criteria: aggregate cross-repository landing. The current service rejects that operation.

Optional routing-only check: edit both Home paths and inspect the aggregate Change plus each repository-local child revision. Do not treat aggregate landing as a pilot outcome.

Before expansion, validate access, compliance, support, pilot terms, two-way sync, and rollback with the Vex team as part of the pilot plan.

Availability ledger

Know what you are evaluating.

Available / assisted

Physical repository federation, Home checkout, history attribution, and owner-routed submission

Operating scope

Hosted source, durable Changes, dependency-aware review, the ordered Merge Queue, and commit-bound Agent Transcripts for supported harnesses

Pilot scope

GitHub coexistence, pull-request projection, and two-way sync that must be proven per pilot

Verifying

Native Vex CI runners and the documented GitHub Actions compatibility subset

Product direction

Federated aggregate landing, atomic cross-repository landing, and a unified build or dependency graph

Current workflowSource control CoexistenceGitHub sync Future directionProduct vision