Support volume:// Named Volumes in CLI Mode

Title

volume:// resource URI mounts are logged but not applied in CLI mode

Description

When using volume://name:container-path syntax in the CLI (either via -v flag or from registry permissions.write), ToolHive logs that it's adding the mount but then shows a warning and does not actually create the mount.

Steps to Reproduce

1. Create a local registry file:

{
  "servers": {
    "test-server": {
      "image": "alpine:latest",
      "permissions": {
        "write": ["volume://my-test-volume:/app/data"]
      }
    }
  }
}

2. Set the registry and run:

thv config set-registry ~/registry.json
thv run test-server

3. Check container mounts:

docker inspect test-server | jq ".[0].Mounts"
# Returns: []

4. Check logs:

cat ~/Library/Application\ Support/toolhive/logs/test-server.log | grep -i volume
# Shows: Warning: Resource URI mounts not yet supported: volume://my-test-volume

Expected Behavior

Docker named volumes should be created and mounted, similar to:

docker run -v my-test-volume:/app/data alpine

This would allow:

• Zero-setup data persistence (Docker manages the volume)
• No mkdir -p prerequisites for users
• Seamless registry-based installation without manual volume flags

Actual Behavior

• ToolHive logs Adding volume mount: volume://my-test-volume -> /app/data (read-write)
• Then logs Warning: Resource URI mounts not yet supported: volume://my-test-volume
• Container starts with no mounts

Environment

• ToolHive version: v0.6.14 (also tested v0.6.15)
• Platform: macOS (darwin/arm64)
• Container runtime: Docker Desktop

Related

• The volume:// syntax appears to be documented and parsed, but implementation is incomplete for CLI mode
• Path-based bind mounts (/host/path:/container/path) work correctly from registry permissions.write
• This may already work in Kubernetes mode (as PVC references) but not CLI/Docker mode

Suggested Implementation

When ToolHive sees volume://name:container-path:

1. Create a Docker named volume if it doesn't exist
2. Mount it at the specified container path
3. Handle both permissions.read (read-only) and permissions.write (read-write)

This would match Docker's native behavior:

docker run -v my-volume:/app/data  # Creates volume if needed

Start at the CLI handling for the -v flag and registry permissions.write entries, then trace where the volume:// warning is emitted. Verify the Docker container configuration and named-volume behavior for both read-only and read-write mounts; done means the volume is created or reused and appears at the requested container path.