the cheapest openclaw upgrade is actually just a folder
before you change models again, give your agent one local place to check the commands, failures, versions, and rules that match your actual machine.
old operating material makes openclaw worse faster than most people expect.
a stronger model won’t f*cking fix stale notes.
one github issue from two releases ago starts looking official once the model says it with confidence.
a copied command from an old install guide turns into “the fix.”
last week’s memory file still mentions a channel you already removed.
suddenly, the assistant gives advice for a machine that no longer exists.
some openclaw stacks fail because the install is broken.
plenty fail earlier because nobody wrote down the current truth of the machine.
openclaw has enough moving parts already
the gateway connects chat apps and channel surfaces to ai coding agents, with support for discord, google chat, imessage, matrix, microsoft teams, signal, slack, telegram, whatsapp, zalo, and more.
openclaw obviously isn’t a normal chatbot.
it sits between messages, tools, sessions, memory, skills, providers, files, browser access, and whatever else you wired into the stack.
small mismatches change the answer.
mac os behaves differently from wsl2.
a vps fails in ways your laptop doesn’t.
telegram and whatsapp have separate pairing, delivery, and channel problems.
local memory brings different limits than remote memory.
one personal assistant has a different risk profile than a multi-agent setup doing client work.
github currently points new users toward openclaw onboard as the recommended cli setup path. it walks through gateway, workspace, channels, and skills, with macos, linux, and windows through wsl2 listed as supported paths.
node version matters too. current install docs list node 24 as recommended and node 22.16 plus as supported.
good information.
still not enough after the setup becomes personal.
a beginner gets stuck on one painful question:
what do i type next?
experienced operators get trapped inside a worse one:
which instruction still matches my current machine?
local-first docs answer that second question.
what local-first docs means
make a folder on your computer or server.
put your current openclaw notes inside it.
tell the agent to search those notes before it answers setup, update, channel, memory, browser, plugin, routing, or recovery questions.
skip databases, vector stores, and architecture diagrams for the first pass.
think of the folder like a binder for your stack.
it lives on your machine.
your assistant reads it before pretending it knows your machine.
later, technical operators might index the folder with sqlite, full-text search, git, checksums, version tags, and source labels.
the first version should stay plain.
the advanced version should stay inspectable.
why this is showing up now
local-first agent tooling keeps moving toward plain files, sqlite, full-text search, and version-specific docs.
one hacker news project described building library docs into a local sqlite file so an ai agent queries version-specific documentation without internet access. the builder called out stale api patterns, rate limits, markdown files, fts5, and bm25-style ranking.
another hacker news project used markdown and git as the source of truth for an agent-maintained wiki, then added a bm25 plus sqlite index on top.
a newer local memory engine thread used sqlite, sqlite-vec, fts5, cli, http, and mcp while keeping everything local.
that pattern matters for openclaw.
memory only helps after the underlying notes are current.
the folder i’d build first
create this folder:
openclaw-local-docsadd these files:
openclaw-local-docs/
00-readme.md
01-current-stack.md
02-tested-commands.md
03-known-failures.md
04-trust-boundaries.md
05-source-log.md
06-update-history.md
07-memory-setup.md
08-channel-setup.md
09-browser-policy.md
10-rollback-steps.mdkeep the first version rough.
each file is a plain note.
give the agent a better place to look before it starts inventing steps.
start with the current machine
write the setup you’re using today.
leave the planned setup out.
ignore last month’s config.
document today’s machine.
# current stack
os:
ubuntu 24.04 on hetzner vps
openclaw version:
2026.5.x
node version:
node 24
gateway:
default gateway process
channels:
telegram and slack
browser:
disabled
memory:
local markdown only
models:
primary cloud model for reasoning
local ollama model for cheap checks
risk rules:
no payments
no outbound email without approval
no production file edits without approvaluse unknown when you don’t know.
pretending costs more.
store commands that already worked
keep a file for commands tested on your actual machine.
copied advice doesn’t belong here.
verified beats long.
# tested commands
## check openclaw version
command:
openclaw --version
success:
prints the installed openclaw version.
common failure:
openclaw is not installed, the shell path is wrong, or the terminal is using the wrong environment.
## start gateway
command:
openclaw gateway
success:
gateway starts without a fatal error.
common failure:
check config, port use, auth, channel setup, or missing dependencies.boring file.
high value.
the agent stops guessing and starts checking.
turn failures into reusable context
known failures save future time.
they also stop the assistant from treating last week’s problem like a fresh mystery.
# known failures
## telegram did not respond after gateway restart
date:
2026-05-16
symptom:
telegram message sent, no response from openclaw.
fix:
restarted gateway and checked pairing status.
did not help:
rewriting the agent prompt.
next time:
check channel status before editing instructions.write the ugly parts down.
gateway failed after update.
whatsapp session expired.
memory search disappeared.
browser tool hit a permission wall.
plugin update got weird.
cron didn’t fire.
agent kept using an old command.
filed pain becomes speed later.
draw the permission line
trust boundaries stop the assistant from guessing what safe means.
that gets messy fast.
# trust boundaries
approval required:
- sending email
- touching payment tools
- editing production files
- using a logged-in browser profile
- installing plugins or skills
- writing long-term memory
- changing channel config
- deleting logs
- running sudo commands
allowed without approval:
- read local docs
- summarize logs
- list likely causes
- draft commands for review
- suggest the next safe checkopenclaw gets useful because it reaches real tools.
stale instructions become expensive for the same reason.
track where the facts came from
a source log keeps the folder from becoming another junk drawer.
# source log
## official openclaw docs
source:
docs.openclaw.ai
used for:
gateway, channels, setup, channel behavior
confidence:
high
last checked:
2026-05-16
## openclaw github readme
source:
github.com/openclaw/openclaw
used for:
setup path, node version, onboarding guidance
confidence:
high
last checked:
2026-05-16
## personal terminal session
source:
my own machine
used for:
commands that worked here
confidence:
high for this machine only
last checked:
2026-05-16now the agent sees what came from official docs.
terminal-tested notes sit in their own lane.
machine-specific facts stop masquerading as universal instructions.
that separation matters when the answer might trigger a shell command, change config, or touch a live channel.
the prompt that changes the agent
after the folder exists, give your agent this instruction: