Journey · Step 06

Current state

At this point the environment behaves like one system. The laptop is the fast execution layer. OpenClaw on the VPS is the persistent memory and orchestration layer. Hooks and scripts connect events into memory. GitHub is the external version boundary. The security model keeps the private parts private.

Previous: GitHub and publishing Back to Journey

Goal

Describe the system as it exists today, including the role of each layer, how the pieces communicate, and why the architecture is shaped the way it is.

1. Local execution layer

The laptop as the working front end

The laptop remains the place where active work happens. Repositories live there. Shell commands run there. Claude and Codex are invoked there. This layer is optimized for fast iteration, file editing, and immediate task execution. 

/Users/example/dev/
/Users/example/dev/project-a
/Users/example/dev/project-b
/Users/example/bin/

2. Local agent layer

Claude and Codex as working agents

Both agents are used because they are useful in different ways. Claude is strong for structured reasoning, repo guidance, and multi-step analysis. Codex is strong in code-heavy workflows and implementation passes. The environment keeps both available so the tool can match the task. 

claude --help
codex --help

3. Local script layer

Small scripts handle the glue work

The scripts under the local bin/ directory connect the layers together. They are intentionally small and role-specific.

  • claude_stop_hook.sh captures session-end context
  • git_daily_sync.sh handles repository-oriented sync or maintenance behavior
  • claude_setup_audit.sh checks Claude-related setup and guidance files
  • codex_setup_audit.sh checks Codex-related setup state

These scripts are useful because they turn operational habits into named, inspectable components.

4. Remote persistence layer

OpenClaw on the VPS

OpenClaw runs remotely so continuity survives local restarts, laptop shutdowns, and tool restarts. It is the persistent layer that stores memory, owns the workspace, and coordinates tool access. 

/home/example/.openclaw/workspace
/home/example/.openclaw/workspace/AGENTS.md
/home/example/.openclaw/workspace/MEMORY.md
/home/example/.openclaw/workspace/memory/

5. Memory model

Workspace files + daily notes + durable memory

OpenClaw uses workspace files for startup context, daily notes for recent events, and MEMORY.md for durable facts. This is one of the most important structural choices in the whole setup. 

# workspace bootstrap files
AGENTS.md
SOUL.md
USER.md
TOOLS.md
HEARTBEAT.md

# long-term memory
MEMORY.md

# daily notes
memory/YYYY-MM-DD.md

6. Ingestion layer

Hooks and parsers feed events into memory

Commits, session endings, and other relevant events are pushed into the memory layer through hooks and helper scripts. This is what keeps the system cumulative. 

~/.git-hooks/post-commit
/Users/example/bin/claude_stop_hook.sh
/Users/example/bin/git_daily_sync.sh

7. Private network path

Tailscale, loopback binding, SSH tunnel, firewall

The memory and orchestration layer stays private. Tailscale provides the private network path. The gateway stays loopback-bound. SSH can bridge local access where needed. The provider firewall keeps the public edge narrow. 

# private path
# laptop -> Tailscale -> VPS -> localhost-bound service

# optional bridge
ssh -N -L 3000:127.0.0.1:3000 user@example-vps

8. GitHub boundary

Versioned code and public publishing stay outside the memory layer

GitHub holds the repositories and publishing workflows. It keeps code, docs, and static site content versioned and visible outside the live memory system. 

git remote -v
git push -u origin main

9. OpenClaw components in practice

CLI, workspace, tools, skills, and runtime behavior

OpenClaw in this setup is more than a CLI. It provides the workspace, the session runtime, the memory layer, the available tools, and the skills that shape how work gets done.

  • CLI for setup and runtime interaction
  • workspace files for startup behavior and continuity
  • memory files for durable and daily context
  • skills for specialized behaviors such as GitHub, summaries, weather, and coding support
  • tool runtime for file editing, shell execution, and orchestration

The point is not to list features. The point is that these components work together to make the environment usable as an actual system.

10. The system flow today

How the parts actually connect

A typical flow now looks like this: the user works from the laptop, invokes Claude or Codex, changes files in a local repo, git events and session endings feed OpenClaw, OpenClaw stores the context in the VPS workspace, and GitHub receives the versioned result when changes are pushed. 

# simplified flow
# user -> laptop -> Claude/Codex -> repo changes
# repo + hooks -> OpenClaw memory on VPS
# final code/docs -> GitHub
# public site -> GitHub Pages

Why the architecture looks like this

Fast local work

The laptop is still the right place for active task execution, editing, and quick iteration.

Stable remote memory

The VPS is the right place for memory, orchestration, and anything that should outlive one local session.

Clear boundaries

GitHub, OpenClaw memory, local scripts, and the private network path each do a different job. That separation keeps the system legible.

Security by structure

Private services stay private. Public services stay minimal. The safest move is usually the boring one.