CDE and Podman Support for the Unbound Force Ecosystem

[jflowers]

Overview

Run OpenCode and the full Unbound Force toolchain (Dewey, Replicator, Gaze, uf) inside a Podman container for security through isolation. If an agent goes off the rails, the blast radius is contained to the container — the host repo stays untouched until changes are explicitly extracted.

Supports:

• macOS arm64 (MacBook Pro)
• Fedora amd64 (workstation/server)
• Eclipse Che / Red Hat Dev Spaces (CDE)

Problem

Today, AI agents run with full access to the host filesystem. A destructive command, a corrupted git history, or a runaway process affects the real project. There is no isolation boundary between the agent's workspace and the engineer's files.

Proposed Solution

1. Container Image (quay.io/unbound-force/opencode-dev)

Multi-arch OCI image (arm64 + amd64) containing the full toolchain:

Tool	Purpose
OpenCode	AI coding agent (headless server mode)
uf	Scaffold, doctor, setup
Dewey	Semantic knowledge layer (MCP server)
Replicator	Multi-agent coordination (MCP server)
Gaze	Go static analysis
Go 1.24+	Build/test
Node.js + npm	OpenSpec CLI
Git, gh CLI	Version control, GitHub operations
golangci-lint, govulncheck	Quality gates

Ollama runs on the host — container connects via DEWEY_EMBEDDING_ENDPOINT=http://host.containers.internal:11434. Keeps the image light and embeddings fast.

Base image options:

• quay.io/fedora/fedora:latest for local Podman use
• quay.io/devfile/universal-developer-image:latest for CDE/Dev Spaces (UDI already has Go, Node.js, Git)
• Tools installed via go install (no Homebrew/Linuxbrew in container)

2. uf sandbox CLI Command

Orchestrate the multi-step container workflow in a single command:

uf sandbox start              # start container + attach TUI
uf sandbox start --detach     # start container, print URL
uf sandbox attach             # attach to running container
uf sandbox stop               # stop and remove container
uf sandbox extract            # git format-patch from container to host

What uf sandbox start does:

1. Check prerequisites (Podman, Ollama, API keys)
2. Detect platform (arm64/amd64, macOS/Fedora, SELinux)
3. Pull/cache the container image
4. Start container with correct volume mounts, env vars, resource limits
5. Wait for opencode serve health check (/global/health)
6. Run opencode attach (or return URL if --detach)

What uf sandbox extract does:

1. Run git format-patch inside container
2. Present the patch for human review
3. Apply on confirmation (git am)

3. CDE / Eclipse Che / Dev Spaces Integration

Devfile 2.2.0 workspace definition:

Option A: UDI + postStart (no custom image needed)

• Use Universal Developer Image as base
• postStart command installs UF tools via go install + curl
• Slower workspace start but no image to maintain

Option B: Custom image in devfile (fast startup)

• Reference quay.io/unbound-force/opencode-dev in devfile
• All tools pre-installed, workspace starts immediately

4. Deployment Models

Model A: Interactive Development

podman run -it --rm \\
  -v ./project:/workspace:Z \\
  -e DEWEY_EMBEDDING_ENDPOINT=http://host.containers.internal:11434 \\
  quay.io/unbound-force/opencode-dev

Engineer gets a shell with the full toolchain. Changes write to mounted volume.

Model B: Headless Server (Maximum Isolation)

podman run -d --rm -p 4096:4096 \\
  -v ./project:/workspace:ro \\
  -e OPENCODE_SERVER_PASSWORD=changeme \\
  --memory 8g --cpus 4 \\
  quay.io/unbound-force/opencode-dev \\
  opencode serve --port 4096 --hostname 0.0.0.0

Read-only source mount. Agent works on a copy. Changes extracted via git format-patch.

Model C: CDE / Dev Spaces

Eclipse Che workspace with devfile.yaml. opencode serve as an endpoint. Connect via browser or opencode attach from host.

5. Security Model

Layer	Protection
Podman rootless	No root access, no daemon, user namespace isolation
Read-only mount (Model B)	Host filesystem untouched
No push credentials	Container has no SSH keys or git push tokens
Resource limits	--memory 8g --cpus 4 prevent runaway
SELinux (Fedora)	:Z relabeling for MAC enforcement
Network control	Can restrict to --network=none for workers
Non-root user	Container runs as unprivileged user
Ollama on host	Embedding model outside blast radius

6. Change Extraction (Configurable)

Git-based (default, maximum safety):
Agent commits inside container. Host extracts via git format-patch. Human reviews before applying.

Direct volume mount (convenience):
Read-write mount. Agent writes directly. Host reviews via git diff.

Configurable via UF_SANDBOX_MODE=isolated|direct or uf sandbox start --mode isolated.

New Repo: unbound-force/containerfile

unbound-force/containerfile/
├── Containerfile                    # Multi-arch image (Fedora base)
├── Containerfile.udi                # Multi-arch image (UDI base for CDE)
├── devfile.yaml                     # Eclipse Che / Dev Spaces workspace
├── devfile-dynamic.yaml             # UDI + postStart (no custom image)
├── scripts/
│   ├── install-uf-tools.sh          # go install for all UF tools
│   ├── entrypoint.sh                # Container entrypoint
│   ├── extract-changes.sh           # Git format-patch extraction
│   └── connect.sh                   # Host-side attach script
├── podman-compose.yml               # Local Podman orchestration
├── README.md
└── .github/workflows/
    └── build-push.yml               # CI: multi-arch build, push to quay.io

uf sandbox in the Meta Repo

New internal/sandbox/ package + Cobra command in cmd/unbound-force/:

internal/sandbox/
├── sandbox.go         # Core logic (start, stop, attach, extract)
├── detect.go          # Platform detection (arch, SELinux, Podman version)
├── config.go          # Container config (image, volumes, env, limits)
└── sandbox_test.go    # Tests with mock exec

Dependencies

Dependency	Status	Blocks
Containerfile repo creation	Not started	Image build
Dewey startup timeout fix (dewey#36)	Open	Dewey works in container
Dewey relative path fix (dewey#40)	Open	Sibling repo indexing in container
Replicator init command (replicator#5)	In progress	uf init in container

Open Questions

1. Should the Containerfile use multi-stage builds (build stage with Go, runtime stage without Go toolchain)? Or keep Go in the final image since agents need go test?
2. Should uf sandbox support running multiple concurrent containers (different branches/tasks)?
3. Should the CDE devfile support attaching Chrome DevTools MCP for browser automation inside the container?
4. Image tag strategy: semver matching uf releases, latest, or nightly?
5. For CDE/Dev Spaces: should tools be installed via devfile postStart commands (using UDI, no custom image) or via a pre-built custom image extending UDI?

Related

• OpenCode server docs: https://opencode.ai/docs/server
• OpenCode web docs: https://opencode.ai/docs/web
• Devfile 2.2.0 spec: https://devfile.io/docs/2.2.0/devfile-schema

[jflowers]

Update: CDE Is the Primary Workflow, Not a Deployment Option

After further design work (issue #95), the framing of this discussion needs correcting. The original proposal presented three deployment models as equals:

• Model A: Interactive Development (local Podman)
• Model B: Headless Server (local Podman, isolation)
• Model C: CDE / Dev Spaces

This is wrong. CDE is not "Model C" — it is the primary production workflow for the iterative demo loop.

Why CDE Is Critical

The core human judgment workflow is the demo loop:

/unleash → demo → human reviews → /speckit.clarify → /unleash → demo → ...

The human exercises judgment not in code review (the Divisor council handles that) but in seeing the working result and deciding if it meets their intent.

In the local Podman workflow, this loop is painful:

1. Agent works inside container (isolated)
2. uf sandbox extract → git format-patch → git am
3. Compile on host
4. Demo / test on host
5. Human says "change X"
6. Re-enter sandbox, re-orient, repeat

Every iteration requires extract → compile → demo → feedback → re-enter. Context is lost between iterations.

In the CDE workflow (Eclipse Che / Dev Spaces), the loop is tight:

1. Agent works inside workspace (persistent)
2. Agent runs tests inside workspace
3. Demo happens inside workspace (Che IDE terminal tab, browser tab, API endpoint)
4. Human reviews in Che IDE, says "change X"
5. /speckit.clarify updates the spec (inside same workspace or pushed via git)
6. /unleash resumes (same context, same files, same compiled binaries)
7. Demo again

No extraction. No recompilation. No context loss. The workspace persists across /unleash runs AND across OpenCode sessions.

Updated Architecture

┌──────────────────────────────────────────────────┐
│  Engineer's Host Machine                         │
│                                                  │
│  ┌──────────────────┐  ┌──────────────────────┐  │
│  │ opencode attach  │  │ Che IDE (browser)     │  │
│  │ (TUI terminal)   │  │ - file viewer/editor  │  │
│  │                  │  │ - terminal tab (demo) │  │
│  │ Slash commands:  │  │ - web app tab (demo)  │  │
│  │ /unleash         │  │ - API endpoint (demo) │  │
│  │ /speckit.clarify │  │                       │  │
│  │ /cobalt-crush    │  │ Human reviews here    │  │
│  │ /finale          │  │ Human edits spec here │  │
│  └────────┬─────────┘  └──────────┬───────────┘  │
│           │                       │               │
│           └───────┐   ┌───────────┘               │
│                   ▼   ▼                           │
│         ┌─────────────────────┐                   │
│         │ Che Workspace       │                   │
│         │ (persistent pod)    │                   │
│         │                     │                   │
│         │ opencode serve :4096│                   │
│         │ dewey serve         │                   │
│         │ replicator serve    │                   │
│         │ /workspace (source) │                   │
│         │ .uf/ (state)        │                   │
│         │ go, node, uf, gaze  │                   │
│         └─────────────────────┘                   │
└──────────────────────────────────────────────────┘

Two access paths to the same workspace:

1. opencode attach from host terminal — where the engineer runs slash commands
2. Che IDE in browser — where the engineer views files, edits specs, and demos the result

Updated CLI Lifecycle

The current start/stop model (Spec 028) is ephemeral. The CDE workflow needs persistent workspaces:

uf sandbox create    → provision persistent workspace
uf sandbox start     → start a stopped workspace
uf sandbox stop      → stop workspace (preserve state)
uf sandbox destroy   → tear down + delete all state
uf sandbox attach    → connect opencode TUI (existing)
uf sandbox status    → show state (existing)
uf sandbox extract   → Podman fallback only (existing)

Updated Deployment Model Priority

Model	Purpose	Priority
CDE (Che / Dev Spaces)	Primary workflow — persistent workspace, iterative demo loop, dual access paths	Primary
Local Podman (headless)	Fallback for engineers without Che/Dev Spaces access	Secondary
Local Podman (interactive)	Quick one-off isolated sessions	Tertiary

Design Decisions Since Original Discussion

Decision	Outcome
Source sync	Bidirectional git (engineer and agent both push/pull same branch)
Demo types	CLI (terminal tab) + web apps (browser tab) + API (curl/exposed endpoint)
Persistence	Workspace survives across OpenCode sessions, /unleash runs, stop/start cycles
Ollama in CDE	K8s service or external URL (not host.containers.internal)
API keys in CDE	K8s secrets or Che user preferences (not host env vars)
CDE platforms	Eclipse Che (open source) + Red Hat OpenShift Dev Spaces (enterprise)

Tracking

• Spec 028: uf sandbox base command (PR feat: add uf sandbox command for containerized OpenCode sessions (Spec 028) #93, merged)
• Issue feat: extend uf sandbox with create/destroy lifecycle and CDE backend #95: create/destroy lifecycle + CDE backend
• Issue fix: add workflow phase boundary guardrails to prevent spec-phase code changes #92: Workflow phase boundary guardrails
• containerfile#1: Container image + devfiles (closed)
• CDE validation guide (planned)