@aviorun/cli
v0.4.4
Published
Bring the setup on this machine to your Avio home, sealed: config, MCP servers, skills, agents, memory.
Readme
@aviorun/cli
Brings the setup on this machine to your Avio home. Run it once on the laptop where your harnesses already work:
npx @aviorun/cli importIt scans what Claude Code, Codex and opencode have left under your home (config, MCP servers, skills, agents, memory, sessions), the repositories they worked on and the files each checkout ignores, then asks one question at a time:
Step 1 Which repositories bring their files and what this machine remembers of them?
Step 2 Which files does a clone not bring? (.env, .claude/scratch/ …)
Step 3 Which harnesses move?
Step 4 Which config moves?
Step 5 Which skills and agents move?
Step 6 Which memories and transcripts move?Each answer narrows the next question: drop a harness and its skills are never offered; drop a repository and neither its files nor its memory are offered. A step with nothing under it is not asked. Then a review of where every ticked thing lands, what stays here and why, and one confirm. Say yes and it prints a link and a code: open the link on any device where you are signed in to Avio, type the code, and the upload starts. The link and the code are the two halves of one approval; a link without the code approves nothing, and so does the code without the link. Paste neither anywhere: whoever holds both for the next five minutes receives your files on their machine. This machine never holds your Avio session, only a one-hour grant that can write files under your home and nothing else.
Logins stay here. A harness login is one refresh chain, and a copy of it on two machines is two
holders of one chain: the first to refresh kills the other. So the command moves no
.credentials.json, auth.json or hosts.yml; you sign in on the home once, from the panel's
terminal, and every thread runs on that.
Every file is sealed on this machine to your home's own key before it leaves, the way a message
is sealed to a recipient. The API relays a box it cannot open; the home opens it where the file
belongs. An .env crosses nothing in the clear.
Piped or scripted, there are no questions: the tree is printed and --yes uploads what is ticked
by default.
A checkout's ignored files are what its committed .gitignore files ignore: the .env a clone never
brings. A file only your own .git/info/exclude or global excludes file hides is left out, since
the home would show it as untracked.
Nothing ignored is hidden from you; a long list is folded instead. .env.local and
.env.production are two rows by name, and a folder holding more than three small ignored files,
and no ignored folder, is one row for the folder, weighed whole and showing how many files it
carries (.claude/scratch/ 4 files). A file past a megabyte or an ignored folder is never folded
in beside them, so app/.env.local stays its own ticked row next to a 33 MB app/.probe/. Ticking it uploads those files one by one under
repos/<owner>/<name>/ beside the clone on your home, and never a file git tracks: what a
folder carries is git ls-files --others --ignored, so a file you force-added stays behind.
A file under a megabyte and a folder under ten are ticked for you; anything heavier is on the
screen with its weight, unticked, and yours to tick. Never node_modules, dist, build,
.next, .cache, coverage, target, vendor, .turbo, .venv, __pycache__ or .git.
Memory follows its repository onto the home's clone path. Transcripts are off by default
(--sessions brings Claude's; Codex's are keyed by this machine's paths and stay). MCP entries
are listed but not moved yet.
--scan print the tree and stop; nothing leaves this machine
--json the same inventory as JSON, and stop
--sessions tick transcripts
--yes no picker: upload what is ticked by default
--home <dir> scan another directory
--api <origin> another API (AVIO_API sets it too)Avio can read none of it. What you tick goes to your own machine, sealed on the way.
