Vibe Code OpenClaw?

[merry ermine]

@sly spoke

I'm using OpenClaw, I want to update it's UI and add features but it keeps crashing.

Should I clone it and modify the clone with the one I cloned? Run two instances of the app. One to vibe code with and the other to modify?

That way I have a version that doesn't crash and I can keep upgrading it?

While using its features such as communicate with it from my mobile device to work on it on the go?

And what about when there are Git updates? How do I prevent over modifications from stopping getting Git updates?
Should I only create skills/plugin features and UI features?

How do features get shared without causing conflicts when a git update happens?

[sly spoke]

Yes—clone (or better: fork on GitHub + clone your fork) if you want to change OpenClaw’s core code or UI. But if your goal is “custom features without fighting git updates”, the best practice is:

1) Keep “your customization” outside the repo

OpenClaw is designed so tailoring lives in:

• Config: ~/.openclaw/openclaw.json
• Workspace: ~/.openclaw/workspace (skills, prompts, memories)

That way you can git pull upstream without constantly resolving conflicts in your personal tweaks. Docs: https://docs.openclaw.ai/start/setup

A nice pattern is to make ~/.openclaw/workspace its own private git repo (your stuff, versioned independently).

2) Only change the repo when you’re actually building upstreamable product features

If you’re changing the Control UI or Gateway behavior, do it in a fork and try to keep changes:

• small
• isolated to a few files
• regularly rebased/merged from upstream

Long-lived forks with lots of UI edits tend to become merge-conflict factories—so when possible, aim to contribute changes back upstream (PR), and keep your “personal” bits in the workspace/skills.

3) “How do I prevent modifications from blocking git updates?”

Two strategies:

• Preferred: implement the feature as a skill / workspace-level extension (no core edits)
  Docs: https://docs.openclaw.ai/tools/skills and https://docs.openclaw.ai/tools/clawhub
• If it must be core/UI: keep it on a feature branch in your fork and routinely sync from upstream (git fetch upstream, then rebase/merge). Don’t hack directly on main.

4) Mobile/on-the-go usage while you develop

Totally doable—your “dev gateway” can still talk over channels (Telegram/Discord/etc.) or you can use the browser Control UI. The key is: don’t point your dev build at a messy/unstable state directory unless you mean to.

5) About the crashing

Before picking an architecture, it helps to pin down what is crashing:

• What does openclaw --version show?
• Is it the Gateway, the Control UI, or a specific tool/channel?
• Any stack trace / last ~30 lines from logs? (docs mention logs commonly under /tmp/openclaw/)
  Troubleshooting hub: https://docs.openclaw.ai/gateway/troubleshooting