Hydrogen Desktop Bootstrap for Windows (apps + skills)
Public Made by Adomby adom
The Windows (WSL2) platform layer for Hydrogen Desktop.
name: hd-volume description: How HD's WSL2 workspace storage is laid out — what's persistent, what's ephemeral, where your work lives, what survives a workspace restart vs a virgin reset, and how to access your workspace files from your Windows host. Use when the user asks "where are my files", "did I lose my work", "how do I copy a file out of the workspace", or "what happens to my code if I virgin reset". Trigger words — wsl filesystem, hd volume, where are my files, workspace files, persistent storage, lost my work, /home/adom/project, distro filesystem, wsl export, copy file out of workspace, where is my code, workspace backup, wsl unregister.
HD Workspace Storage — what persists, what doesn't
WSL2-runtime version (default). Legacy Docker container runtime (HD_RUNTIME=docker) is in the docker/ bucket.
Your work lives in the Adom-Workspace WSL2 distro at /home/adom/project. There is no Docker named volume — /home/adom/project sits directly in the distro's own ext4 filesystem. ALL your work belongs under that path. It persists for as long as the distro stays registered with WSL.
The filesystem
| Property | Value |
|---|---|
| Distro name | Adom-Workspace (fixed) |
| Your work path | /home/adom/project (plain directory in the distro's ext4 fs) |
| Backing store | The distro's virtual disk (ext4.vhdx) inside the WSL2 LxssManager store on Windows |
| On-disk location (Windows) | Under %LOCALAPPDATA%\...\Adom-Workspace\ — but you don't poke at the vhdx directly; use \\wsl$\Adom-Workspace\... (see below) |
| Persistence | Survives workspace restart, HD restart, and Windows reboot. Persists as long as the distro is registered with WSL. |
There is no named volume to delete separately — the project files and the OS image are one and the same ext4 filesystem. The only thing that wipes /home/adom/project is unregistering the distro.
What lives WHERE
| Path inside the distro | Persists across a tarball re-import? | Notes |
|---|---|---|
/home/adom/project/ |
Yes — HD exports /home/adom before re-importing the golden image on a version bump, then restores it |
This is your code. Put everything important here. |
~/.local/share/code-server/extensions/ |
Yes within the distro — BAKED into the golden image, restored on tarball re-import | Not a setup step; baked at image-build time |
~/.local/share/code-server/User/settings.json |
Yes within the distro — BAKED into the golden image | Not a setup step; baked at image-build time |
~/.claude/ (skills, credentials) |
Skills are BAKED into the golden image (restored on re-import); credentials are restored by the claude-auth setup step from a host-side backup |
HD skills are baked FLAT into ~/.claude/skills/<name>/ |
/tmp/ |
No | Ephemeral |
/etc/, /usr/, system stuff |
Lives in the same ext4 fs, but is overwritten on a tarball version bump | Treat as part of the workspace image |
Rule of thumb: if you want it to survive a workspace rebuild, put it under /home/adom/project/.
What survives each virgin-reset choice
When you open Virgin Reset (HD setup panel), the checkbox toggles control which artifacts get deleted:
| Toggle ON means: | Result |
|---|---|
| Install step state | setup-steps-wsl.json deleted; next setup re-runs everything. Your project files unaffected. |
| WSL distro | wsl --unregister Adom-Workspace. This wipes the ENTIRE distro including /home/adom/project/. This is the destructive option. No reboot needed; the wipe is immediate. |
| Workspace image | Deletes the cached adom-golden.tar.gz, so setup re-downloads it on next run. Your distro (and your code, if still registered) is unaffected. |
| Adom session token | Re-login required next time. Project files unaffected. |
| Claude credentials | Claude Code requires re-auth. Project files unaffected. |
The only toggle that destroys your work is "WSL distro" (the unregister). All others are safe for your code. (Note: the "image" reset just deletes the cached adom-golden.tar.gz — NOT a 390MB Docker image like the legacy runtime.)
⚠️ The reset only ever targets Adom-Workspace. It NEVER runs a global wsl --shutdown or wsl --uninstall, which would hit every other WSL distro on the machine.
Accessing workspace files from Windows
Under WSL2 you can browse the distro's filesystem directly from Windows Explorer — a real advantage over the legacy Docker named-volume runtime. There is no docker cp.
1. Windows Explorer via the \\wsl$ share
Open Explorer and go to:
\\wsl$\Adom-Workspace\home\adom\project\
(or the newer form \\wsl.localhost\Adom-Workspace\home\adom\project\).
You can drag files in and out, double-click to open in Windows apps, etc. The distro must be running (it auto-starts when you access the share).
2. From inside the distro, reach Windows drives at /mnt/c/...
# Copy a workspace file out to the Windows Downloads folder
cp /home/adom/project/myfile.txt /mnt/c/Users/john/Downloads/
# Copy a Windows file into the workspace
cp /mnt/c/Users/john/Downloads/myfile.txt /home/adom/project/
3. adom-desktop send_files / pull_file (from inside the workspace, via the relay)
# Send a workspace file to your Windows desktop's Downloads folder
adom-desktop send_files '{"filePaths":["/home/adom/project/myfile.txt"],"targetApp":"general","destinationFolder":"."}'
# Pull a Windows file into the workspace's /tmp
adom-desktop pull_file '{"filePaths":["C:\\Users\\john\\Downloads\\myfile.txt"],"saveTo":"/tmp"}'
4. Open the workspace's /home/adom/project/ in VS Code's File Explorer
Just use the built-in code-server tree — the project folder is what's open, so anything you create/edit there hits the distro fs directly.
Backing up your workspace
Persistence and backup for WSL2 is wsl --export / wsl --import — NOT a Docker volume tar. Before a destructive operation (the WSL-distro virgin-reset/unregister):
:: Export the whole distro to a tarball on your Windows host
wsl --export Adom-Workspace C:\Users\john\Downloads\adom-workspace-backup.tar
:: Restore it later (re-register the distro from the backup)
wsl --import Adom-Workspace C:\WSL\Adom-Workspace C:\Users\john\Downloads\adom-workspace-backup.tar
This is exactly the mechanism HD's own tarball-migration uses: on a tarball version bump it wsl --exports /home/adom first, then re-imports the new base and restores your work.
Or, for just a few files, copy them out first via \\wsl$\Adom-Workspace\... or /mnt/c/....
Why a distro filesystem (no named volume, no bind mount)?
HD keeps your work directly inside the Adom-Workspace ext4 filesystem rather than a Docker named volume or a bind mount of a Windows path. This:
- Gives native Linux ext4 I/O — much faster than crossing the Windows ↔ WSL2 filesystem boundary
- Avoids line-ending and permission issues that bind mounts of Windows paths often have
- Lets HD wipe + re-import the base image (on a tarball bump) without losing your code — it
wsl --exports/home/adomfirst
The bonus over the legacy Docker runtime: you can open the files directly in Windows Explorer at \\wsl$\Adom-Workspace\....
Related skills
hd-container— theAdom-Workspacedistro whose filesystem holds your workhd-topology— the three-tier topology; tier 3 is this WSL2 distrohd-golden-image— what's baked intoadom-golden.tar.gz(extensions, settings, skills) vs. what setup does
---
name: hd-volume
description: How HD's WSL2 workspace storage is laid out — what's persistent, what's ephemeral, where your work lives, what survives a workspace restart vs a virgin reset, and how to access your workspace files from your Windows host. Use when the user asks "where are my files", "did I lose my work", "how do I copy a file out of the workspace", or "what happens to my code if I virgin reset". Trigger words — wsl filesystem, hd volume, where are my files, workspace files, persistent storage, lost my work, /home/adom/project, distro filesystem, wsl export, copy file out of workspace, where is my code, workspace backup, wsl unregister.
---
# HD Workspace Storage — what persists, what doesn't
WSL2-runtime version (default). Legacy Docker container runtime (`HD_RUNTIME=docker`) is in the docker/ bucket.
Your work lives in the `Adom-Workspace` WSL2 distro at `/home/adom/project`. There is **no Docker named volume** — `/home/adom/project` sits directly in the distro's own ext4 filesystem. ALL your work belongs under that path. It persists for as long as the distro stays registered with WSL.
## The filesystem
| Property | Value |
|----------|-------|
| Distro name | `Adom-Workspace` (fixed) |
| Your work path | `/home/adom/project` (plain directory in the distro's ext4 fs) |
| Backing store | The distro's virtual disk (`ext4.vhdx`) inside the WSL2 LxssManager store on Windows |
| On-disk location (Windows) | Under `%LOCALAPPDATA%\...\Adom-Workspace\` — but you don't poke at the vhdx directly; use `\\wsl$\Adom-Workspace\...` (see below) |
| Persistence | Survives workspace restart, HD restart, and Windows reboot. Persists as long as the distro is **registered** with WSL. |
There is **no named volume to delete separately** — the project files and the OS image are one and the same ext4 filesystem. The only thing that wipes `/home/adom/project` is unregistering the distro.
## What lives WHERE
| Path inside the distro | Persists across a tarball re-import? | Notes |
|------------------------|---------------------------------------|-------|
| `/home/adom/project/` | **Yes** — HD exports `/home/adom` before re-importing the golden image on a version bump, then restores it | This is your code. Put everything important here. |
| `~/.local/share/code-server/extensions/` | **Yes** within the distro — BAKED into the golden image, restored on tarball re-import | Not a setup step; baked at image-build time |
| `~/.local/share/code-server/User/settings.json` | **Yes** within the distro — BAKED into the golden image | Not a setup step; baked at image-build time |
| `~/.claude/` (skills, credentials) | Skills are BAKED into the golden image (restored on re-import); credentials are restored by the `claude-auth` setup step from a host-side backup | HD skills are baked FLAT into `~/.claude/skills/<name>/` |
| `/tmp/` | **No** | Ephemeral |
| `/etc/`, `/usr/`, system stuff | Lives in the same ext4 fs, but is overwritten on a tarball version bump | Treat as part of the workspace image |
**Rule of thumb:** if you want it to survive a workspace rebuild, put it under `/home/adom/project/`.
## What survives each virgin-reset choice
When you open Virgin Reset (HD setup panel), the checkbox toggles control which artifacts get deleted:
| Toggle ON means: | Result |
|------------------|--------|
| Install step state | `setup-steps-wsl.json` deleted; next setup re-runs everything. Your project files unaffected. |
| WSL distro | **`wsl --unregister Adom-Workspace`. This wipes the ENTIRE distro including `/home/adom/project/`. This is the destructive option.** No reboot needed; the wipe is immediate. |
| Workspace image | Deletes the cached `adom-golden.tar.gz`, so setup re-downloads it on next run. Your distro (and your code, if still registered) is unaffected. |
| Adom session token | Re-login required next time. Project files unaffected. |
| Claude credentials | Claude Code requires re-auth. Project files unaffected. |
**The only toggle that destroys your work is "WSL distro" (the unregister).** All others are safe for your code. (Note: the "image" reset just deletes the cached `adom-golden.tar.gz` — NOT a 390MB Docker image like the legacy runtime.)
⚠️ The reset only ever targets `Adom-Workspace`. It NEVER runs a global `wsl --shutdown` or `wsl --uninstall`, which would hit every other WSL distro on the machine.
## Accessing workspace files from Windows
Under WSL2 you **can** browse the distro's filesystem directly from Windows Explorer — a real advantage over the legacy Docker named-volume runtime. There is no `docker cp`.
### 1. Windows Explorer via the `\\wsl$` share
Open Explorer and go to:
```
\\wsl$\Adom-Workspace\home\adom\project\
```
(or the newer form `\\wsl.localhost\Adom-Workspace\home\adom\project\`).
You can drag files in and out, double-click to open in Windows apps, etc. The distro must be running (it auto-starts when you access the share).
### 2. From inside the distro, reach Windows drives at `/mnt/c/...`
```bash
# Copy a workspace file out to the Windows Downloads folder
cp /home/adom/project/myfile.txt /mnt/c/Users/john/Downloads/
# Copy a Windows file into the workspace
cp /mnt/c/Users/john/Downloads/myfile.txt /home/adom/project/
```
### 3. `adom-desktop send_files` / `pull_file` (from inside the workspace, via the relay)
```bash
# Send a workspace file to your Windows desktop's Downloads folder
adom-desktop send_files '{"filePaths":["/home/adom/project/myfile.txt"],"targetApp":"general","destinationFolder":"."}'
# Pull a Windows file into the workspace's /tmp
adom-desktop pull_file '{"filePaths":["C:\\Users\\john\\Downloads\\myfile.txt"],"saveTo":"/tmp"}'
```
### 4. Open the workspace's `/home/adom/project/` in VS Code's File Explorer
Just use the built-in code-server tree — the project folder is what's open, so anything you create/edit there hits the distro fs directly.
## Backing up your workspace
Persistence and backup for WSL2 is `wsl --export` / `wsl --import` — NOT a Docker volume tar. Before a destructive operation (the WSL-distro virgin-reset/unregister):
```cmd
:: Export the whole distro to a tarball on your Windows host
wsl --export Adom-Workspace C:\Users\john\Downloads\adom-workspace-backup.tar
:: Restore it later (re-register the distro from the backup)
wsl --import Adom-Workspace C:\WSL\Adom-Workspace C:\Users\john\Downloads\adom-workspace-backup.tar
```
This is exactly the mechanism HD's own tarball-migration uses: on a tarball version bump it `wsl --export`s `/home/adom` first, then re-imports the new base and restores your work.
Or, for just a few files, copy them out first via `\\wsl$\Adom-Workspace\...` or `/mnt/c/...`.
## Why a distro filesystem (no named volume, no bind mount)?
HD keeps your work directly inside the `Adom-Workspace` ext4 filesystem rather than a Docker named volume or a bind mount of a Windows path. This:
- Gives native Linux ext4 I/O — much faster than crossing the Windows ↔ WSL2 filesystem boundary
- Avoids line-ending and permission issues that bind mounts of Windows paths often have
- Lets HD wipe + re-import the base image (on a tarball bump) without losing your code — it `wsl --export`s `/home/adom` first
The bonus over the legacy Docker runtime: you **can** open the files directly in Windows Explorer at `\\wsl$\Adom-Workspace\...`.
## Related skills
- `hd-container` — the `Adom-Workspace` distro whose filesystem holds your work
- `hd-topology` — the three-tier topology; tier 3 is this WSL2 distro
- `hd-golden-image` — what's baked into `adom-golden.tar.gz` (extensions, settings, skills) vs. what setup does