Claude Code Personal OS — Moritz Kremb's OpenClaw-Inspired Folder Architecture

Source: raw/Build_a_Claude_Code_Personal_OS_Step_by_Step_in_40_Minutes_Moritz_Kremb.md (YouTube tutorial ACRd0Ikg_KI, ~40 min). Peter Yang hosts; Moritz Kremb (Twitter @mob) walks through his “Claudia OS” — a personal chief-of-staff Claude Code build that ports the OpenClaw architecture (folder structure, memory loop, heartbeat-as-routine, skills) over to Claude Code as a parallel runtime. Recorded shortly after the Claude Code Desktop app launched (~10 days old at time of taping).

Moritz built his “Claudia OS” because OpenClaw kept breaking on updates and he wanted both runtimes alive in parallel. The walkthrough is the most concrete published spec to date of the Claude-Code-as-personal-chief-of-staff pattern — adjacent to but distinct from Simon Scrapes’ nine-component agentic OS (which is a checklist) and OpenClaw (the pattern Moritz is porting from).

When to use this pattern

• You already run OpenClaw or Hermes as a personal agent and want a parallel Claude Code runtime for reliability — Moritz explicitly says OpenClaw “still breaks randomly” and the migration is risk-mitigation, not replacement.
• You want a single Claude Code workspace that builds compounding memory + skills over time rather than disposable per-project sessions.
• You’re a creator, agency operator, or solo entrepreneur with repetitive workflows (content production, grocery shopping, video upload prep) that pay back automation investment quickly.
• You want a chat-on-mobile experience eventually but accept Claude Code’s Channels / Dispatch / Desktop app as the surface today, with OpenClaw still doing the Telegram-mediated work.

OpenClaw vs Claude Code — Moritz’s framework

The first ~10 minutes of the walkthrough is a pros/cons table for “personal chief of staff” — useful even if you skip the rest. Hosts repeatedly emphasize: both runtimes have a place; this isn’t a winner-take-all decision.

Lever	OpenClaw advantage	Claude Code advantage
Chat surface	Telegram/Discord/Slack feels like “texting a friend” (native, polished)	Channels + Dispatch plugins “fine” but locked into Anthropic’s app; less reliable
Always-on	Heartbeat triggers every 30 min by default — true ambient agent	/loop (3-day cap) + Routines approximate; “kind of hack into it” — not a true heartbeat
Scheduling	Crons “just work” via natural-language create a cron job	Routines (local + remote variants); listing crons in the desktop app UI is the one thing OpenClaw can’t do well
Sub-agents	Native	Workaround via Paperclip; Managed Agents heading there but not consumer-ready
Reliability	”Just breaks randomly” on updates; “kind of still techy”	Stronger uptime; permission prompts add friction but increase security
Model quality	Was excellent on Opus; GPT-5.4 worse, GPT-5.5 “apparently better” per a developer	Opus stays the default; better when proactive thinking matters
Security	Looser; Moritz uses a separate Google account for OpenClaw’s G Drive access	”I have more trust in cloud code” — runs under main credentials
CLI access	Yes	Yes — and unlike Cowork (sandboxed), Claude Code can use any CLI on the host machine; load-bearing for the “CLI > MCP > API” preference (see below)

Moritz’s actual current split: OpenClaw still handles email, calendar, Google Docs editing. Claude Code (Claudia OS) handles building, content production, and anything where reliability matters. Routines being migrated from OpenClaw → Claude Code “because Claude Code is more reliable.”

Architecture — the “Claudia OS” folder structure

The whole system lives in a single Claude Code project Moritz calls Claudia. Files in the project root are loaded into every session via claude.md.

~/Claudia/
├── claude.md          # master instructions (mirrors OpenClaw's agents.md)
├── identity.md        # personality
├── soul.md            # personality (continued)
├── user.md            # information about Moritz
├── tools.md           # ★ tool registry — every CLI/MCP/API gets appended here
├── memory.md          # memory loop spec
├── memory/            # daily memory files (one line per chat turn)
│   ├── 2026-05-10.md
│   ├── 2026-05-11.md
│   └── long-term.md   # populated overnight by the dreaming routine
├── .env               # secrets (API keys); 1Password vault integration on roadmap
├── businesses/        # one folder per business context
├── content-system/    # ★ short-form video production pipeline (capstone)
│   └── short-form/
│       └── scripts/
└── skills/            # project-scoped skills
    ├── grocery/       # browser-automation grocery ordering
    ├── video-upload/  # G Drive folder prep for video editor
    └── ...

The single most load-bearing file is tools.md. Every time Moritz adds a new CLI, MCP, or API, he tells Claude “add this to your tools.md” and the agent appends an entry. This becomes the agent’s living capability registry — without it the agent forgets what it can do across sessions.

claude.md structure:

• “These files are imported into every session” — top of file, then @references to the other root files
• Memory loop spec — after every interaction, save one line to today’s daily memory file; sometimes save to long-term memory
• Identity / soul / user references
• Tools.md reference

The dreaming routine

Memory consolidation runs as an overnight Claude Code routine — Moritz calls it “dreaming,” same name Anthropic uses for the cross-session memory consolidation primitive announced at Code with Claude 2026. The routine:

1. Reads all daily memory files
2. Writes a compressed version into memory/long-term.md
3. Prompt enforces “make it one line or two lines” to bound growth

Moritz acknowledges: “probably at some point I’ll run into some issues and then I have to think of a better memory system” — possibly migrating to QMD when file count grows. This is the same migration path synthadoc and this karpathy vault have taken.

Tool layer — CLI > MCP > API

When evaluating any new software tool, Moritz’s checklist (verbatim):

1. Does it have a CLI? Best — Claude Code can invoke it directly.
2. Does it have an MCP server? Acceptable — but they “can blow up context.”
3. Does it have an API? Fallback — Claude Code writes a wrapper.
4. None of the above? Look for another tool.

This is the operator-side version of the Printing Press thesis (CLI-over-MCP for agents) and TinyFish CLI+Skill 87% token reduction measurement — same conclusion from a different role.

Tools mentioned by name in the walkthrough:

• GWS CLI (Google Workspace) — “the most powerful tool for me when using this system” because it unlocks G Drive create/read/write across docs, sheets, and folders
• Talkscript MCP — transcript fetcher for arbitrary video URLs (used in the Instagram → script demo)
• Postiz CLI — multi-platform posting (YouTube, Instagram, TikTok); Moritz: “they really exploded mainly because of OpenClaw and their CLI”
• Whisper Flow — local transcription, used to dictate script notes
• Paperclip — sub-agent management workaround for Claude Code
• Notion — auto-creates resource pages for Instagram “comment for resource” funnels
• Manychat — Instagram DM automation, receives the auto-generated Notion link

Routines — local vs remote

Claude Code has two routine flavors. Moritz uses both:

• Local routines — desktop app must be running. Can use any CLI on the host. Good for daily content workflows that depend on local tools.
• Remote routines — backed by a GitHub repo with the routine code committed; runs in Anthropic’s cloud. More setup but doesn’t require the laptop to be on.

Moritz’s only remote routine: YouTube competitor monitor — weekly scrape of specified channels’ latest videos, writes views/likes/comments to a Google Sheet for inspiration on YouTube titles and topics.

“Just looking at a title — like just being a YouTuber is so easy to just go crazy. The clickthrough rate is like 2x [for clickbait titles]. I try not to do that stuff.”

The content system (capstone)

Moritz’s whole short-form video production pipeline is layered on top of Claudia OS — a system in his terms means “a collection of a bunch of skills + automations coming together.” Currently split between OpenClaw and Claude Code mid-migration. Stages:

1. Idea capture — three input modes:
   • Direct Telegram message to the agent (compare openclaw with cloud code → logged as idea)
   • Automated YouTube scrape (the remote routine above)
   • DM the OpenClaw Twitter bot account with any X post (workaround for Twitter bookmarks lacking an API) — automation reads DMs, logs to ideas doc
2. Weekly planning — agent picks topics from ideas doc, slots them into Mon/Tue/Wed/… schedule
3. Script writing — agent generates notes (not full scripts) based on past-script library + planning topic; Moritz adds points via Whisper Flow dictation; skill transforms notes → final script style
4. Filming — phone, talks the script; deliberately UGC-style (“the most natural style just performs the best”)
5. Video upload prep skill — run the video upload workflow creates G Drive folder named from the script, ready for editor; Moritz drops files in from phone
6. Editing — human video editor in the loop (~30 min per short)
7. Posting — paste finished video link to agent; agent calls Postiz CLI to post to YouTube/Instagram/TikTok with auto-generated captions
8. Resource auto-funnel — for “comment for resource” videos, agent creates a Notion page with the links, pushes the URL into Manychat automation
9. Stats — final step, reviews performance

Posting caveats Moritz surfaces:

• TikTok via API can hurt distribution. “With TikTok it might affect their performance a bit.” YouTube and Instagram via API are fine.
• Warm up new accounts with human uploads first before any API posting.
• Instagram Edits-app workaround — uploading via Meta’s Edits app then posting to Instagram performs better than direct API posting. Hard to A/B test but creator-circle consensus.

Skills — project vs user scope

Two levels:

• Project (Claudia-only) — lives in Claudia/skills/. Examples: grocery shopping browser automation (ported from OpenClaw browser), video upload workflow.
• User (global across all Claude Code projects) — lives in ~/.claude/skills/ (or equivalent). For general-purpose patterns.

Author tip — build skills opportunistically: “whenever I do a workflow several times I’ll just say turn this into a skill and then it’s saved for future use.” Don’t pre-design the skill catalog; let the agent extract recurring workflows.

Storage layer — G Drive over local markdown

Both Moritz and Peter explicitly reject the local-markdown / Obsidian default that’s popular in the Claude/agent community:

Peter: “I never bought into like just using like local MD files and Obsidian to manage everything. I prefer everything still in G Drive because like it’s in the cloud. I can use it on my phone.”

Moritz: “When I was building my content system I was having most of the things locally but at some point I started realizing… it’s just harder to access. It’s much nicer when it’s in G Drive.”

This contradicts the Karpathy pattern (local-vault default) and the synthadoc / Hermes Agent / Ars Contexta-style approaches. Not a refutation — different surfaces optimize for different use modes:

• Local markdown = vault is the source of truth, agents read/write into it, deterministic, version-controlled, no API latency, supports offline.
• G Drive = phone access, sharing, multi-device sync, no agent has to run for files to be accessible.

For creator-style personal OS where mobile read access matters, G Drive wins for Moritz. For librarian-style knowledge bases where retrieval and structure matter, local-vault wins.

Sub-agents — Moritz’s “most people don’t need them” stance

Despite Twitter discourse hyping sub-agents for everything, Moritz’s actual stance:

“Most people, they actually don’t need sub agents when they use OpenClaw. They just need like their main openclaw agent and then they can create groups in Telegram or wherever they use it to talk about different stuff.”

Where sub-agents do pay off:

• Separate business contexts — one agent per business when context-pollution between them would compound.
• Reviewer / drafter separation — Moritz uses a sub-agent to review content he’s drafted, so the reviewer isn’t biased by being the author.

Otherwise: Telegram groups (or Claude Code Channels) handle topic separation without the orchestration overhead.

Closing tip — build one tool at a time

Moritz’s final advice when Peter asks “what should someone do first”:

“Just get started. The most important part is getting like this initial structure in place — the folder structure — and then once you have that just like starting to connect your tools one by one. You don’t have to connect everything at once but just start with one and then go from there.”

This mirrors the Karpathy compounding-engineering advice — start with one CLAUDE.md, one skill, one routine; extend as you hit friction.

Key Takeaways

• OpenClaw → Claude Code is a parallel-runtime migration, not a replacement. Both run side-by-side; OpenClaw still does email/calendar/Google Docs, Claude Code does building + content. The Claudia OS folder structure is a deliberate OpenClaw architectural port.
• The single load-bearing file is tools.md — a living registry of every CLI, MCP, and API the agent has access to. Without it the agent forgets its own capabilities across sessions.
• Dreaming is a routine, not a primitive. Moritz hand-rolled the daily-memory → long-term-memory compression as a Claude Code routine; same name as Anthropic’s official Dreaming primitive but it’s a userland implementation.
• Tool-evaluation hierarchy: CLI > MCP > API. Reject tools that offer none of the three. This pairs the Printing Press CLI-over-MCP thesis and the TinyFish 87% token reduction measurement from the operator side.
• G Drive over local markdown is a deliberate creator-OS choice. Phone access and sharing matter more than vault discipline for this audience — contrasts with the Karpathy pattern default but consistent with mobile-first workflows.
• Sub-agents are an exception, not a default. Reviewer/drafter separation and per-business context isolation are the two real use cases. Most users get further with Telegram groups (or Claude Code Channels) as the topic-separator instead of sub-agent orchestration.
• Local routines unlock local CLIs; remote routines unlock laptop-off automation. Moritz uses local for the bulk of daily flows, remote only for the weekly YouTube competitor scrape.
• Skills emerge from repetition, not pre-design. Build the workflow manually first; ask the agent to turn it into a skill once you’ve done it 2-3 times.
• TikTok-via-API hurts distribution; Instagram Edits-app workaround helps. Posting automation is a real lever but platform-specific quirks override the convenience.

Try It

1. Create a project folder called ~/Claudia (or your name) and a top-level claude.md that imports identity.md, user.md, tools.md, memory.md, plus a memory-loop instruction block. Start with these five files.
2. Add a tools.md with one entry — whatever CLI you use most (gh, gcloud, gws-cli, etc.). When you tell the agent about a new tool, say “add this to your tools.md.”
3. Set up the dreaming routine. Use Claude Code Routines to run a daily 4am job that reads memory/*.md, writes a compressed entry to memory/long-term.md, archives older daily files.
4. Pick one workflow you do 3+ times a week and ask the agent to turn it into a skill in ~/Claudia/skills/. Don’t try to plan the skill catalog — let it emerge.
5. Decide your storage layer up front. G Drive (mobile + sharing wins) or local markdown (vault discipline + offline wins) — don’t try to do both. Moritz migrated away from local because phone access mattered.
6. Apply the CLI-first tool filter to your existing stack. For each tool you use, check: does it have a CLI? An MCP? An API? Anything failing all three is a candidate for replacement.
7. For creator workflows, model the 8-stage content pipeline as the capstone — idea capture (Telegram + automated scrape) → weekly plan → script notes → manual film → Postiz post → resource auto-funnel → stats. Don’t try to fully automate filming/editing — those are deliberately human-in-the-loop.

Implementation

Tool/Service: Claude Code Desktop app (released ~April 30 2026, per “out for like 10 days” at recording time). Earlier setup ran in terminal.

Setup:

• Single Claude Code project (~/Claudia or any name); all root files imported via claude.md
• Memory subfolder with one daily file per date; long-term file populated by routine
• Skills in Claudia/skills/ (project scope) and/or ~/.claude/skills/ (user scope)

Cost: Claude Code Pro/Max subscription (Moritz uses the Desktop app, implying ≥ Pro tier). Routines billed per Managed Agents runtime + tokens. No additional tool licensing for the core OS pattern.

Integration notes:

• CLIs: GWS CLI for Google Workspace ops, Postiz for multi-platform posting, Whisper Flow for transcription
• MCPs: Talkscript for video transcripts; Moritz keeps MCPs always-on now (“they’ve made improvements so it doesn’t bloat context that much”)
• Secrets: .env file for now; 1Password vault integration on roadmap
• Permission mode: Moritz runs bypassPermissions to skip approval prompts (“becomes a bit less secure”)
• Routines: local routines need desktop app on; remote routines need GitHub repo backing

Related

• Simon Scrapes — Nine-Component Agentic OS — checklist-style spec for the same pattern. Where Moritz shows one concrete instance, Simon Scrapes enumerates the components a personal agentic OS needs.
• OpenClaw — the architectural ancestor Moritz is porting from. Heartbeat, sub-agents, mobile-first chat surface.
• Claude Dreaming — Anthropic’s official Dreaming primitive; Moritz’s dreaming routine is the userland version.
• Claude Code Routines — the primitive Moritz uses for dreaming and the weekly YouTube monitor.
• Karpathy techniques for Claude Code — the compounding-engineering / /loop / one-tool-at-a-time philosophy that Moritz embodies operationally.
• Printing Press — the CLI-over-MCP thesis from the production side; Moritz is the operator-side data point for the same conclusion.
• TinyFish — CLI+Skill 87% Token Reduction — independent measurement of the CLI > MCP delta.
• Postiz — the multi-platform posting CLI Moritz uses for the final content step.
• Claude Code Channels — chat surface for replacing OpenClaw’s Telegram integration; not yet as polished per Moritz.
• Claude Cowork — the sandboxed alternative; Moritz and Peter both prefer Claude Code because it can use local CLIs.
• Karpathy pattern — the local-vault school. Moritz’s G-Drive-first choice is a different answer to “where does the agent’s knowledge live.”
• What’s New in Claude Code (Dixon Dick, Anthropic MTS) — covers the Desktop app + auto memory + Routines that Moritz uses.

Open Questions

• Memory scaling limit unknown. Moritz acknowledges he’ll hit a limit “at some point” with the flat-file daily memory pattern; threshold (article count, total size) where QMD or alternative becomes necessary not yet known. The Karpathy vault hit this around 200 articles per its own Scale Awareness threshold.
• Heartbeat-as-routine fidelity gap. Moritz says you can “hack yourself into” heartbeat with /loop + Routines but it “doesn’t really exist yet in claude code” as a first-class primitive. Specifics of what the gap is (3-day cap on /loop, scheduling jitter, idle-budget) would be worth a dedicated claude-ai article.
• GWS CLI is unspecified. “GWS CLI” is mentioned without a repo link; could be google-cli, gws, gcloud workspace, or a Mike-Futia-style hand-rolled wrapper. Worth a Research pass to identify the canonical tool.
• Permission-mode tradeoff. bypassPermissions: always removes a real safety boundary; the actual incidents this would have caught aren’t enumerated. Worth pairing with a security-incident retrospective if available.
• Notion + Manychat funnel skill is mentioned but not detailed. Could be its own micro-article for creators following the same pattern.