Components

The parts of the system

The environment works because each part has a clear role. The laptop, the agents, the scripts, OpenClaw, GitHub, the memory files, and the private network path each solve a different problem. This page breaks those parts down one by one and shows what they actually do in the larger workflow.

Home Next: Decisions

1. Laptop

The active execution layer

The laptop is where day-to-day work actually happens. Repositories are edited there, shell commands run there, and agent sessions are started there. Keeping this layer local preserves speed and reduces friction. 

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

This layer is responsible for interactive work. It is the place where code changes are made, docs are edited, and tasks are run in real time.

2. Claude

Structured reasoning, guidance, and repo analysis

Claude is part of the working agent layer. It is especially useful for guided implementation, architecture discussion, documentation, cleanup passes, and repo-level reasoning. 

claude --help
claude --print --permission-mode bypassPermissions "Your task here"

In the wider system, Claude is not just a chat interface. It is a tool that can read repos, update files, reason about workflows, and feed useful context back into the memory layer through the Stop-hook path.

3. Codex

Implementation-heavy coding work

Codex is also part of the active agent layer, with a stronger role in code-heavy implementation passes and repo-local edits. 

codex --help
codex exec "Implement the requested change"

In practice, the environment benefits from having both Claude and Codex available because the tool can match the kind of task rather than forcing every job through one model.

4. Helper scripts

Small automation pieces with narrow jobs

The scripts in the local bin/ directory are the glue between the local machine, the agents, and OpenClaw. They are useful because they take repeated operational behavior and turn it into named, inspectable components. 

/Users/example/bin/claude_stop_hook.sh
/Users/example/bin/git_daily_sync.sh
/Users/example/bin/claude_setup_audit.sh
/Users/example/bin/codex_setup_audit.sh

Each script has a narrow role:

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

5. OpenClaw

The persistent memory and orchestration layer

OpenClaw is the durable layer behind the local tools. It provides the workspace, memory files, session runtime, tool surface, skills, and orchestration model that make the environment cumulative. 

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

OpenClaw matters because it gives the system a stable home outside the local shell session.

6. Workspace files

The files that make continuity possible

The core workspace files define startup behavior, voice, user context, tool notes, heartbeat behavior, and durable memory boundaries. 

AGENTS.md
SOUL.md
USER.md
TOOLS.md
HEARTBEAT.md
MEMORY.md
memory/YYYY-MM-DD.md

These are not decorative docs. They are operational files. The startup sequence, the user-specific context, the durable facts, and the daily notes all live here.

7. Skills and tool surface

Specialized behavior lives on top of the runtime

OpenClaw also exposes a tool/runtime surface and a set of skills that extend what the environment can do in a structured way.

  • GitHub operations
  • coding-agent delegation patterns
  • weather, summarization, and other utility skills
  • memory search and retrieval
  • session and sub-agent orchestration

The value is not in having lots of tools. The value is in giving the system specialized capabilities without turning everything into one giant general-purpose prompt.

8. GitHub

The external record and publishing boundary

GitHub stores repositories, commit history, workflows, and the public site. It is the versioned outer edge of the system and the place where final code and docs live. 

git remote -v
git push -u origin main

9. Tailscale and firewall

The private network and exposure boundary

Tailscale provides private connectivity between the laptop and the VPS. The firewall keeps the public edge narrow. Together they define which parts of the system are reachable and which are intentionally private. 

# private path
# laptop -> Tailscale -> VPS -> localhost-bound service
# public edge only for web-facing services that need it