feat: add raw openclaw config editor

[tspader]

Summary

We need a way to let users get their machines out of bad states. Since we don't provide full remote access, this PR adds a widget to fetch the openclaw.json from the live machine, let the user patch it arbitrarily, and send the updated config back to the machine. OpenClaw hot reloads configs.

Details:

• Added new controller routes, /_kilo/config/replace and /_kilo/config/read
• Tried to separate "your instance needs to be updated to pull in the new routes" from "failed to reach instance" in the status codes
  • 401 => unauthorized
  • 404 => your instance doesn't have the route yet
  • 409 => anything else (not provisioned, unreachable)
• Lazy load @monaco-editor/react for a reasonable inline JSON editor with highlighting + validation
• Don't do any validation beyond "is this valid JSON"; trying to keep track of OpenClaw's config through some Zod schema that we maintain is a fool's errand
  • Similarly, the config payload is an opaque blob in the Zod schema
• Added Edit Config to the danger zone since it is dangerous

Verification

I loaded this up in my dev environment and made sure that:

• You can't send a malformed config
• You CAN send a well-formed config
• Any changed keys persist across restarts
• Refetching the config to hand-edit again always loads the freshest config

Visual Changes

Before	After

And the editor proper:

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (25 files)

• kiloclaw/DEVELOPMENT_LOCAL.md
• kiloclaw/controller/bun.lock
• kiloclaw/controller/package.json
• kiloclaw/controller/src/atomic-write.test.ts
• kiloclaw/controller/src/atomic-write.ts
• kiloclaw/controller/src/config-writer.test.ts
• kiloclaw/controller/src/config-writer.ts
• kiloclaw/controller/src/proxy.test.ts
• kiloclaw/controller/src/proxy.ts
• kiloclaw/controller/src/routes/config.test.ts
• kiloclaw/controller/src/routes/config.ts
• kiloclaw/scripts/push-dev.sh
• kiloclaw/src/durable-objects/gateway-controller-types.ts
• kiloclaw/src/durable-objects/kiloclaw-instance/gateway.ts
• kiloclaw/src/durable-objects/kiloclaw-instance/index.ts
• kiloclaw/src/routes/platform.ts
• src/app/(app)/claw/components/OpenclawConfigEditor.tsx
• src/app/(app)/claw/components/SettingsTab.tsx
• src/hooks/useKiloClaw.ts
• src/lib/kiloclaw/config-redaction.test.ts
• src/lib/kiloclaw/config-redaction.ts
• src/lib/kiloclaw/kiloclaw-internal-client.ts
• src/lib/kiloclaw/types.ts
• src/lib/trpc/init.ts
• src/routers/kiloclaw-router.ts

---

_{Reviewed by gpt-5.4-20260305 · 1,311,271 tokens}

[St0rmz1]

Good work overall — atomic writes, etag concurrency, backup before replace, solid test coverage. Leaving inline comments on a few things worth addressing or documenting.

[St0rmz1]

Duplicate entry for ' 'Config was modified ' ?

[St0rmz1]

nit (non-blocking): sanitizeOpenclawConfigError forwards code to the client on all three paths, including the generic fallback where the message is intentionally redacted. Today the codes are all safe constants (config_read_failed, config_etag_conflict, etc.), so this is fine in practice. But as a future hardening consideration, Path 3 could restrict code passthrough to the OPENCLAW_CONFIG_ERROR_CODES allow list, same as it does for messages, so a future controller change can't accidentally leak internal details via the code field:

// Current
return { message: `${operation} failed`, status, ...(code ? { code } : {}) };

// Hardened
return { message: `${operation} failed`, status, ...(code && OPENCLAW_CONFIG_ERROR_CODES.has(code) ? { code } : {}) };

Not blocking since the tRPC layer in kiloclaw-router.ts provides a second defense via UNSAFE_ERROR_CODES.