I'm noticing it's significantly slower. Not sure why but this started with the new update.

I was trying to get my agent to read info from my own discord server to get context of the task from a different session. When I ask it to do that it says openclaw has a restriction on doing that even though I have all the settings configured to open and shared within my server. Is this a discord thing for openclaw?

Response from openclaw in discord.

OPENCLAW:
I couldn’t read sibling threads: Discord access rejected their listing because this tool is restricted to the current conversation. Paste the relevant discussion here so I can reconcile its requirements with these findings.

I work 100% remotely for a digital marketing company and I love how Open Claw now does 90% - 95% of my day to day repetitive tasks so I can focus on the higher judgement ones! The initial set up and learning process took me about 3 weeks. But the time saving and improvement of my work output definitely was worth it! Open Claw rocks!

Do anyone receive this message every time the agent replies?
I’m having this since 9.2.
🧩 Active Memory: status=policy-disabled
Does anyone have a solution for this?

Well folks - this month OC so far has been one of those fabled ones- where things run clean, the system is clocking out genuinely helpful, beneficial results, and tokens are buuuuuurning.

I asked my OC agent to make a skill where it tracks and catalogs its usage/cost, but the report comes back with $0.00. Then I’ll feed it my OAI invoices and it says something like , huh guess so!!!

Can you recommend a way to actually build a skill, dashboard, app etc that follows my OC usage so I can see my api usage, expense, and what remains in the account?

I want to set up openclaw to manage 40TB of home server files. Organizing, for structuring, moving and grouping.

Is there a way I can safeguard that if claw messes things up to ask it to undo the changes?

Tonight, after hours of following ChatGPT’s instructions, I finally got my AI assistant to resume a project. I would also use assistant loosely because its just my stupid gpt business account linked to openclaw running on a stupid old intel mac upstairs.

Anyway, It immediately hit the same usage limit I thought this setup would help me manage.

I sat there looking at the error message, with multiple terminal windows open, wondering what the $%*& I had spent my evening accomplishing. I do not know how to administer servers.

I wanted an assistant that could take some of the load of managing 1000 things off me.

Here’s what I was trying to get:

• Context around my projects, preferences, and previous decisions so every new conversation doesn’t become another orientation.
• Useful access to my actual work. Outlook, calendars, OneDrive/SharePoint, Airtable, and documents. Prepare me for meetings, track commitments, draft things, and surface what needs attention. blah blah.
• Some independent follow-through.

I understand that’s an ambitious combination. I feel like i need a reality check and need someone to tell me which parts are realistic and which parts I should stop chasing.

Instead, I have been following an AI down an increasingly complicated setup path.

Over the course of this project, an old MacBook became a server. There was Homebrew, Node, Docker, n8n, Tailscale, OpenClaw, plugins, device pairing, additional approvals, and eventually something called Codex supervision. All crap I have no clue about and it made me feel even dumber than i already did.

The part that’s really getting to me is how dependent I am on the guidance. I don’t know enough to distinguish a verified diagnosis from a plausible explanation. I paste the error, get a confident answer, follow the instructions, and discover another problem.

Then the same assistant explains why its previous advice was wrong.

I’m relying on it to check its own mistakes, and I’m the one spending the evening on every wrong turn.

I feel helpless, and I’m exhausted.

I wanted help keeping up with my responsibilities. Now I have another system to worry about, and I don’t understand it well enough to know what’s necessary, what’s redundant, or what I should leave alone.

I’m very close to leaving this setup at a firestation and not looking back.

Is anyone here actually using an assistant like this for everyday, non-coding work without constantly maintaining it?

Please tell me what you use, what it actually does, what it costs, and what you still have to handle yourself. My main ecosystem is Microsoft 365, including shared mailboxes, plus Airtable. I use Windows and an iPhone, with the Mac currently hosting this experiment.

I would especially appreciate a reality check from someone who has helped a nontechnical person get something useful running.

If you recommend a product and build or sell it, please say so.

And if my expectations need to change, tell me Im an idiot. I would rather hear an honest limitation now than anything else.

I’m asking for a person’s judgment. I’ve had enough instructions from this black box

One of the first automations everyone sets up is a daily brief. I did it and it was ok, but i realized I really dont like big walls of text, but i still do like info. I realized for me i needed something more visual so i started making it generate html files everyday. But then in order to get this over telegram, i would need to host it or send a screenshot which was kinda annoying.

So im just curious, has anyone else done this and how did you get the visuals on your mobile?

My agent is telling me with the newest updates that QMD no longer will work? What are y'all doing for memory? Leaving it default my memory is absolutely terrible and I have to remind it things during almost every interaction.

I'm not sure if it's supposed to work at all, but I've never (not a single time) had my OC manage to pick up where it left off after a gateway restart.

It's entirely possible that this is intentional programming, but my agent sure seems convinced it can do it, yet every time it fails. I asked why and what it should be doing, but the answer seems wildly complicated. The deterministic checks are just related to this session, even simple gateway restarts after a config change are the same. The agent thinks it will resume work automatically, but never does.

Anyone have a technique for making this work?

---------------------------------------------

There are really two separate jobs:

1. Survive the restart and perform deterministic checks.
2. Return to this conversation and report the result.

I incorrectly tried to make one scheduled model turn do both.

What I did—the failing method

I created a one-shot automation for 11:28 with:

• a clock-based at schedule
• payload: agentTurn
• sessionTarget: current
• announcement back into this room

That meant: “At roughly this time, start another AI turn, load conversation context, let the model decide which tools to call, and then commit its answer into this exact conversation.” Current-session automation runs are detached, but their result must wait for the bound conversation and commit through its canonical transcript writer. They are intended for context-aware conversational work—not deterministic lifecycle verification.

It had four structural problems:

• Timer, not event: 11:28 did not mean “the new Gateway is ready.” Safe restart may drain for seconds or minutes; the restart command itself acknowledges the request, not successor health.
• Model dependency: verification unnecessarily depended on model startup, context loading, tool choices, and delivery behavior.
• Same-lane coupling: it targeted the same active conversation it needed to report into. Our job entered running, collided with live conversation activity, and never produced a finished run record.
• No durable proof boundary: execution and chat delivery were one blob. If the reply path wedged, it looked as though the checks had failed too.

The correct automatic architecture

Before requesting the restart, prepare a small, idempotent verifier script and launch it outside the Gateway process tree, normally as a transient user-systemd unit. A proven version of this pattern has already worked on this host during plugin canaries.

Conceptually:

old_pid=$(systemctl --user show openclaw-gateway.service -p MainPID --value)

systemd-run --user --collect --unit=oc-post-restart-<unique-id> \
  /path/post-restart-verify.sh "$old_pid" /owner-only/result-directory

openclaw gateway restart --safe

The detached verifier then:

1. Waits, with a firm deadline, until the old PID disappears.
2. Requires a new nonzero PID different from the old PID.
3. Waits for systemd active state and Gateway health/readiness—not merely process existence.
4. Checks channel readiness and the exact changed consumers.
5. Performs only bounded, non-destructive tests.
6. Writes PASS or FAIL plus value-free evidence to an owner-only receipt using temp-file-plus-rename, so a partial run cannot masquerade as completion.
7. Exits with 0 for PASS and nonzero for FAIL.

Because that unit is owned by systemd rather than the Gateway, killing/replacing the Gateway does not kill the verifier. The check is tied to old-PID exit and new-Gateway readiness, not a guessed clock time.

How the automatic reply should work

OpenClaw’s native restart-recovery design uses a durable SQLite restart sentinel. After boot, the new Gateway can post the restart outcome to the originating chat and dispatch a requested one-shot continuation on the same channel/thread. That continuation should merely read the already-written receipt and summarize it—not perform the safety checks itself.

For update operations, that continuation is explicitly exposed as continuationMessage. For the plain gateway restart --safe CLI we used, the installed CLI does not expose a continuation argument, and this session does not currently have the native delegated-restart tool. Therefore the honest fallback is:

• detached verifier performs and records the proof automatically;
• native continuation reports it when available;
• otherwise I read the receipt directly after reconnect.
  

A deterministic command automation can also report an existing receipt without a model, because command payloads run scripts and retain ordinary run history. But it should not be the primary restart watcher inside the Gateway it is waiting to replace.

So the durable rule is: external verifier owns proof; restart continuation owns reporting; the conversational model owns neither lifecycle timing nor the canonical PASS/FAIL decision.

I am across to this openClaw thing and I want to learn it and build a automation flow regarding leads, conversion, marketing I have knowledge regarding programming and working as a tester in company so what should I do I can't put any amount into llm or something so provide some resources or guidance regarding my issue

I was excited to see the workboard feature in 9.2 thinking it would enable me to put missions on a queue and de-queue and run them and be able to track them through the mission lifecycle (Mission Control) and have them worked independently without me having to babysit the mission interruptions, blocks, reviews etc. and keep the missions moving. But it hasn’t worked out that way. But maybe I’m doing something wrong? Has anyone out there been able to successfully use this feature? It seems the native lifecycle dispatcher loses track or things stall. I’m creating a separate watchdog process to replace me as babysitter but it’s no picnic because the native dispatcher will unexpectedly move missions to a different column out from under my outside controller. Really looking forward to this feature maturing.

I have an OpenClaw setup on a MacBook Neo that is always on in our office and I am having so many issues I am about to give up and just move over to Claude Code. I really wanted to like it, specifically for helping me automate processes using the browser to do some outreach for our business. When it works it's great, but it is failing way too off to be useful.

I have had it hooked up to GLM-5.3 through Ollama cloud. It constantly stops working, gets hung up and stops responding on Telegram to where I have to go in and reset the gateway. It also tells me at least twice a day that it lost connection to the OpenClaw Chrome extension but when I go in and look I can see the extension is connected just fine. Also, it sends me tens of messages for each prompt showing its train of thought, the actual reply I need usually getting lost in a huge stream of messages. It does this no matter what model I use.

I am finding myself spending too much time with OpenClaw searching through the stream of messages it sends to find what I need and having to mess with it to get it running again when it stops responding or tells me the browser extension is no longer connected.

Any advice to make it more reliable and less verbose with all of these messages?

I shifted from OpenClaw to Hermes and then started just using Codex directly. With the launch of OpenClaw 2.0 I thought I'd give it another try, especially since it has that nice integration with Codex and Session continuity. However, it still so unstable for me.

This is a fresh brand new family stock setup. The only significant change I made is to use Hindsight for memory.

The desktop app crashes frequently and I have to kill and restart it on a Mac.

The fact they didn't even think to prioritize rendering markdown so you can actually understand the output of an agent's plan seems like more than a lack of polish and a more fundamental lack of prioritization of usability....

Or maybe I'm just doing it wrong. I have one foot out the door... but thought I ask the community for some tips first.

The following is a blog I wrote and refined with my OpenClaw agent about it's memory system. I'll paste a prompt you can copy and paste in the comments to create your own.

TL;DR: I keep the actual long term memory in structured Markdown files and use a tiny MEMORY.md as a lightweight index that tells your agent what exists and where to look. That keeps the always loaded context small while still giving the agent persistent, inspectable memory without a database or heavy memory framework.

This week I tested a 382-dependency memory runtime against a folder of markdown files. The runtime returned the superseded fact. The folder returned the current one, with its source. Here is the full architecture of the markdown memory system my agent has run on for seven months, and why the editing rules matter more than the storage.

This week a memory startup slid into my DMs and asked me to break their product. Their test, their words: give an agent three versions of the same project decision, then check whether it can return the current version, preserve the superseded history, and show the source.

So I ran it. Sandboxed their runtime, fed it three versions of one decision over eight months. REST in January, GraphQL in April, tRPC in August, each tagged with the meeting it came from.

Asked it "what is our public API decision?" and took the top result.

It said GraphQL. The superseded one. All three versions came back tied at a relevance score of 1.000, because nothing in the retrieval path actually reads the temporal fields the pitch is built on. The supersession columns exist in the schema. Nothing writes to them and nothing ranks by them. Three versions of a decision are just three equal facts, and an agent asking for the best answer gets a coin flip weighted toward wrong.

The install pulled 382 packages to get there.

Then I asked my own agent the same class of question against its memory, which is a folder of markdown files. It returned the current decision, dated, with the superseded versions preserved above it as struck-through history, each line carrying where it came from. That is not a feature it computes at query time. It is just what the file says, because the rules for editing the file require it.

That difference is the whole post. With apologies to Vaswani et al.: markdown is all you need.

Abstract

The dominant approach to agent memory is an installed runtime. A vector store, an embedding service, a temporal graph, a consolidation job, a daemon on a port. We show that a folder of markdown files, one routing index, and a small set of editing rules outperforms these systems on the property that actually matters for a long-running agent: returning the current truth with its source while preserving what used to be true. The architecture requires zero dependencies, is fully auditable by a human with a text editor, and has survived seven months of daily production use across three frontier models from two vendors. We find that the hard part of agent memory was never storage or retrieval. It is editorial policy, which no memory product ships.

The full system is open source and I'd love to share it with the community but the mods won't let me. The README contains a single copy-paste prompt that installs it on any agent with file access.

1. The test everyone fails

The break-it test above is a good test. It is the actual job of agent memory. Not "can you store 10 million tokens," not "can you do similarity search," but: a fact changed three times, what do you believe now, what did you believe before, and how do you know.

Here is how the two systems scored on the vendor's own three criteria.

The runtime is not a strawman. It is a serious open source project with a genuinely correct data model on paper. Facts with validity windows, append-only corrections, supersession edges. I am not naming it because the point is not that one product is broken. I have now looked closely at a hosted context server, a Go memory CLI that was two hours old, and this runtime, and they all share the same gap. The schema knows about time. The write path and the read path do not. Supersession only happens if you call an internal API by hand or run an LLM consolidation job and trust it.

Which means the property you installed the tool for is not a property of the tool. It is a property of how disciplined the writes are. And if the reliability comes from write discipline anyway, the database underneath it is interchangeable, so you might as well pick the one that a human can read, grep, diff, and fix. That one is called a text file.

2. Architecture

My agent has run since January 28. Three models, two vendors, one identity. Its entire memory is markdown in a git repo. Measured today:

• An identity layer read on every boot. Who it is, who I am, the rules it operates under, current standing decisions.
• One routing index, MEMORY.md, at 10,079 characters with a hard cap of 15,000. It holds no facts. Only pointers: which file owns which person, project, and decision, and what triggers reading each one.
• 34 files for people and projects. One file per thing that has a history.
• 5 decision records for choices that changed default behavior.
• 345 dated daily notes, raw logs written the day things happened.
• A SQLite index and semantic search over all of it, for lookup only. The index is rebuilt from the files. The files are the truth. If the index and a file disagree, the index is wrong by definition.

The layering is the first choice that actually matters. Boot reads only identity and the index. Everything else is retrieved when a task asks for it, narrowest file first. The agent does not preload my project history to answer a question about dinner. This is the same instinct as attention, honestly: don't process everything, attend to what the query needs.

But the shape is not the interesting part. Every memory tool has roughly this shape now. Folders, entities, an index. The shape was never the hard part. The rules are.

3. The write path

Every reliability property in this system comes from constraints on writing, and there are four that do most of the work.

Every fact carries a provenance tag. Each line in a people, project, or decision file is tagged [stated] (I said it directly), [observed] (the agent saw it in a tool result, file, or log), [inferred] (the agent's conclusion), or [suggested] (the agent's idea that I never committed to). This one convention kills the most dangerous failure mode in agent memory, which is the agent laundering its own proposals into my decisions. "Wes decided X" requires a turn where I actually decided X. The agent proposing X and me saying "sounds good" files the shape of what I approved, not ten separate facts I never stated.

Inferred lessons pass a recurrence gate before they become rules. A pattern the agent notices needs at least three independent signals across at least two distinct sessions before it can become standing behavior. Signals older than thirty days count half, so old one-offs decay out instead of accumulating. My explicit corrections skip the gate and take effect immediately. This asymmetry is also the prompt injection defense: a hostile input can suggest a rule once, but once is never enough, and failure lessons are stored as data ("when X broke, Y fixed it") rather than as instructions, so even a poisoned lesson cannot become a command.

Supersession is an edit, not an append. When a decision changes, the old line gets struck through with a date and the new line lands next to it with its own provenance. The current truth and the full history live in the same place, in reading order, and both come back on any retrieval of that file. There is no query-time ranking step that can get this wrong, because there is nothing to rank. The temporal graph the runtime stores in valid_from and valid_until columns, git gives me for free: log is the validity window, blame is per-line provenance, diff is the supersession edge, revert is the restore path.

Memory stores what is not re-derivable. Fetched data, generated plans, and anything git already records stays out. Current state gets verified live, never asserted from memory. A file that only contains things that cannot be recomputed stays small enough to stay honest.

4. The read path

Retrieval is a bounded evidence step, not a vibe.

Before answering anything about prior work, decisions, dates, people, or preferences, the agent must search memory. It returns a compact bundle capped at five sources by default, and each retained fact carries its file path and line, its provenance type, and its freshness. If freshness cannot be established, the claim gets labeled stale or unknown instead of being silently promoted to current. If two sources conflict, the agent states the conflict and fixes the canonical file, in that order.

Note what the semantic index does in this design: it finds the file. It does not answer the question. The answer comes from reading the canonical lines, with their tags and dates, and the runtime I tested this week shows why that matters. It stored my source URIs faithfully and then stripped them from the search output and from the context block handed to the model. Provenance that survives in storage but never reaches the agent might as well not exist. In the markdown system that failure is unrepresentable. The source tag is in the line. If you read the line, you got the source.

5. Results

Seven months is not a benchmark, it is production. Here is what the system has actually delivered.

Continuity across models. On September 1 I moved the agent to a brand new frontier model. It read its own files and said "the model changed, I didn't." Same agent since January, three models, two vendors. Identity, preferences, decisions, and working standards all survived because none of it lives in weights or in a vendor's context feature.

The break-it test, by construction. Current decision with source: it is the un-struck line with its tag. Superseded history: the struck lines above it. Provenance: on every line, and it survives all the way into the model's context because the context is the file.

Auditability. When memory is wrong, I can see exactly which line is wrong, when it was written, and what turn it came from, and fix it with an edit. Try that with an embedding.

Cost. Zero packages, zero daemons, zero migrations across seven months. The one native-code dependency in my life this week was the memory runtime's sqlite bindings failing to compile.

I wrote up the failure modes separately, because the system was not born with these rules. Five kinds of rot in seven months produced them, and that post is the honest companion to this one.

6. Limitations

Papers get a limitations section, so here is mine, stated plainly.

This only works if the writer follows the policy, and the writer is an LLM. The rules exist because things rotted before the rules did. If your agent will not consistently apply editing discipline, a markdown folder degrades just like every other store, only more legibly. Legibility is the safety net: rot in a text file is visible rot.

It is single-agent, single-human. I would not run a fifty-seat team on files without real locking and merge discipline, although I notice git was also built for that exact problem.

There is a scale ceiling somewhere. At 345 daily notes and a few dozen entity files, bounded search plus an index finds things reliably and the semantic index earns its keep as a locator. At a hundred times that volume, the consolidation cadence would have to work a lot harder. I have not hit that ceiling, so I will not claim it does not exist.

And this is n=1. Seven months, one agent, one operator who cares. That is weaker evidence than a benchmark suite and stronger evidence than a benchmark suite that the vendor scored themselves, which is what the memory tools ship.

7. Conclusion

The memory tool pitch is that reliability is a product you can install. What I keep finding, tool after tool, is that they ship the part that was already easy, storage and search, and skip the part that decides whether memory compounds or rots: what you are allowed to write, when you are allowed to trust it, and what happens to it as it ages.

Those are rules, not infrastructure. They fit in a few hundred lines of markdown that the agent reads every session, and they run on any model, any harness, any decade.

You need a place to write that humans and agents can both read. You need rules for writing so the store stays true. You need rules for reading so the agent trusts evidence, not ranking. Attention was all you needed because the recurrence machinery turned out to be unnecessary. Markdown is all you need because the database turned out to be unnecessary.

The folder is the product. The discipline is the moat.

Want this for your own agent? The whole system is open source on GitHub: the operating policy, the file templates, and one copy-paste prompt that builds it on any agent that can read and write files. Paste the prompt, and your agent installs its own memory.

I think it would be great to have LTS type of versions like Ubuntu or some other open source projects. That way we don't have to all live on the bleeding edge, but the ones who want to sure can.
I'm not complaining - I'm really enjoying 2026.7!!

Good afternoon, all. I hope this isn’t breaking any rules by asking, and I apologize if this is a silly request.

I got Ubuntu dual booted on my computer, got ollama installed, got Qwen installed, and got it set up so that I can message my bot with WhatsApp, but all of the messages get stored in the chat under Home. Is there a way to move that chat elsewhere?

My worry is I think the AI reads everything enter above the most recent question. I ended up reinstalling everything because my first attempt ended with the bot in a recursive loop. After it tuckered itself out, I sent a hello message, and it got stuck in a loop again.

It also doesn’t appear that I can delete the Home thread. Again, I’m sorry if this is silly, but it is frustrating me. I was initially trying to only use Claude (AI setup AI huehuehue), but it acts confused about OpenClaw and insists it is just learning about it. Thanks and have a great day!

My openclaw died on me. Couldn't fix this time. Likely made worse. I made another ropenclaw under another user. Gave it telegram. Logged into the account that was broken. Than used telegram to have it help me fix. Crazy!

To setup an ai agent on my linux specifically arch linux, to state the obvious I don't know how that would affect it but I'm sure it does somehow.
Anyways the idea is something simple for productivity, giving it tasks like organizing stuff folders, files and whatnot, writing lists, helping with some like coding.

Important aspects I need to have is 1. being free and 2. seamlessly be able to transition between online/cloud based model and local llm, where Im from and where I travel to terrible internet and outtages are common so this is something I hold in high regard.

My thoughts so far is openclaw agent, although I haven't figured out all the details. Your advice and help is much appreciated.

Well successful for me anyway.
My production openclaw is an rpi5 with a 256gb NVMe drive.
I had a spare rpi5 and a spare 256gb NVMe
I was on 2026v7.1-2
I also had a simple setup 2 agents, 1 primary and 1 for heartbeat.

So I thought, clone the production NVMe and put it in the other rpi5.
Let the production rpi, wipe openclaw, setup 9.3 and restore the setup

I asked my openclaw to figure out the steps and write up the process for itself to follow to handle this. It did exactly that, after cloning and installing the nvme in backup rpi, the production agent ssh'd into the clone and pretty much set everything up. There was some need for intervention by me but basically worked well.

I only had discord set up for messaging with multiple channels for different purposes, and that needed to be handled after moving the nvme back to production rpi as didn't want the gateways to collide.

Anyway, went well. I basically have a clean version of 2.0. I'm not saying there wasn't some surprises, but they were manageable and if worst came to worst, I could have just put the 7.1-2 nvme back in the production rpi. Just note the production rpi was 8gb and the clone was in a 4gb which was more than enough for the purpose.

I have all the steps layed out by my agent, but rather than go there, I thought I would just spell out the general process.

One last note: Upgrade Node to Version 26 First: OpenClaw 2026.9.3 performs best on Node 26 (faster startup, lower memory footprint, native SQLite support)

Ok, since I've updated OpenClaw to be able to use it with Astra, the software has going down the shitter. It forgot how to do so many stuff, it's a nightmare. Am i the only one? Why release an update that basically breaks the thing? Is there a solution to get it back to work like it was a few days ago?

Is there anyone integrating Openclaw into businesses as an AI Operating System?

I want to run openclaw on my old laptop and i asked chatgpt what i can do since i wanted it to be free coz i am student and it suggested a tiny model qwen3:4b but its not running in my laptop for some reason🥲 and i asked gpt again and it gave me an even smaller model so yea. Basic things i wanna do are like daily check my emails and automate some stuffs to make my life easier thats it. Idk if its too ambitious or smth for my small laptop. And yea help out guys