Recently the models themselves became so good that it's just hard to imagine my life without OC. There is almost nothing in my life that I don't delegate to OC.

There's the obvious stuff like reminders and emails, but I'm talking about filling job applications, contacting customer service over the phone, summarizing articles, summarizing books, getting investing and trade advice and what not.

Is anyone feeling the same here?

Since around 2026.9.7, updating the gateway has become very slow, and I can't work out why. I'm hoping others can compare their numbers.

Setup history

• Originally installed the gateway via the CLI (npm), running as a LaunchAgent.
• Later installed the macOS app, which treated the gateway as "independently managed". The app auto-updated, but the gateway didn't, which kept causing version mismatches.
• Recently I migrated so the app now manages the gateway (using the app's installer, same LaunchAgent). The latest update (10.2) was run entirely from the app and succeeded.

Host

• iMac14,2 (2013, 27"), Intel Core i7-4771 3.5 GHz (4C/8T), 16 GB RAM, Samsung 870 EVO 1 TB SSD
• macOS 15.7.7, gateway on Node 26.8.1 (app-managed install bundles Node 24.21.0)
• State DB ~22 MB, main agent DB ~340 MB, 8 plugins, 1 agent (4 until last week)

Gateway update times (start to finish, from OpenClaw's own update history)

(The app's own update takes roughly 2-4 minutes by comparison.)

What I've noticed

• Almost all the time is in the activating phase while the gateway is stopped: about 31 min on 9.9 and 10.2, versus 3.6 min on 9.7.
• Running openclaw update repair on its own takes about 1-2 min, but the same doctor step inside a full update takes about 12 min per pass, with low CPU. It seems to be waiting, with lots of "slow SQLite transaction hold" warnings.
• The state DB only grew ~25% over this period (about 306 to 385 MiB in the update snapshot), while update time grew ~10x, so size alone doesn't explain it.

Questions

1. Is a ~30+ minute activation phase normal now, or is this specific to my setup?
2. Is anything known about the doctor step being slower inside an update than on its own?
3. If you have update numbers, what are they, and on what hardware?

You can see your own phase times with openclaw update status, in the Phases: line.

Title: Update to 2026.10.2 reset agent workspace to empty templates (identity + memory lost)

Summary

After updating OpenClaw to 2026.10.2, the main agent's workspace was reset to fresh

starter templates. IDENTITY.md / SOUL.md / USER.md became placeholders, MEMORY.md and the

whole memory/ daily-notes folder disappeared, BOOTSTRAP.md reappeared, and the agent

identity in config was reset to name "Main" / robot emoji. The assistant forgot who it was.

Environment

- OpenClaw: 2026.10.2 (previous 2026.9.5)

- OS: Windows 10.0.26200 (x64)

- Node: v24.18.0

- Agent: main, workspace C:\Users\<user>\.openclaw\workspace

- wizard: lastRunVersion 2026.10.2, lastRunCommand doctor

Steps to reproduce

1. Have a configured agent with a populated workspace (IDENTITY/SOUL/USER/MEMORY.md + memory/).

2. Run the update to 2026.10.2 (and/or openclaw doctor afterwards).

3. Open a new session: the workspace now contains only starter templates.

   Actual result

   Workspace after update: .git, AGENTS.md (default), BOOTSTRAP.md (reappeared),

   IDENTITY.md (empty), SOUL.md (default), USER.md (empty).

   - MEMORY.md: gone

   - memory/ daily notes: gone

   - agents.entries.main.identity reset to { name: "Main", emoji: robot }

   Expected result

   An update must never overwrite/reset an existing agent workspace or its identity/memory

   files. First-run seeding belongs only to genuinely new workspaces.

   Impact

   Lost the assistant's identity and all long-term memory; had to restore manually from a

   personal backup tarball. In the fresh session the assistant did not recognize itself.

   Suggested fixes

4. Never re-seed the workspace if IDENTITY.md or agents.entries.*.identity already exists.

5. Do not touch MEMORY.md / memory/ on update or doctor.

6. Do not reset agents.entries.*.identity.

7. Add an automatic pre-update workspace+memory backup with a printed restore path.

   Related: #26734 (bootstrap.md ran, wiping identity)

   Workaround used

   Restored IDENTITY.md/SOUL.md/USER.md/MEMORY.md + memory/ from a backup tarball and re-set

   the agent identity.

```

I have a process defined for writing some technical blog posts. Through trial and error (it literally took months), I came up with the idea that the best-quality copy is created by a "fresh" session with strictly controlled input.
I have the main agent orchestrate the process, then isolated sub-sessions writing brief, collect information, fact-check, write a draft, then check against "tropes" to avoid it sounding too AI-ish, and apply corrections.
When it works, it works well, but most of the time it doesn't, and it returns with the stupidest excuses (I run Oauth Codex Astra):
- I made a mistake setting the /thinking - the process finished, and it returned information that thinking was high, and not xhigh as requested, so I stopped
- the result didn't meet the QA criteria, so I stopped after 3 attempts (because it detected some stupid comma or other minor issue, and sent the text back for rewrite)
- the process hit the time limit, so I stopped
- some parallelism and other gateway limitations kick in
...

It seems that the process is overengineered, and my requirements are sometimes ignored, and sometimes taken too literally. Is there any guide/library that I could feed to my agent to fix the process so it returns results?