Grok Bot update_state memory writes fail fleet-wide: brain docs snapshot was cut short before completing

Support Bug Reports
1

Where does the bug appear (feature/product)?

Grok Bot

Describe the Bug

Summary
update_state with target: memory fails on every bot I tested with the exact error:

brain docs snapshot was cut short before completing

Settings updates via update_state still work. Direct file writes to memory/profile.md and memory/log/*.md still work. Failed memory writes do not reliably land the fact.

Where it happens

Recreated / reimported bots (e.g. after sidebar Delete + reimport): CreateAgent often leaves incomplete agent-data — missing memory/ folder, no conversation-blobs.db, empty latestRootBlobId. Scaffolding memory/ alone does not fix update_state.
Long-lived bots too same error. So this is not recreate-only and not explained by one oversized chat.

Repro

Open any bot (fresh or old).
Ask it to run update_state → target: memory, action: write, short log/note fact.
Observe tool error: brain docs snapshot was cut short before completing.
Confirm the fact is absent from memory/*.md (unless the bot file-appended as a workaround).
Optionally: update_state → target: settings still succeeds on the same bot.

Expected
Memory write succeeds; fact appears in agent memory / prompt snapshots.

Actual
Tool errors; brain-docs snapshot aborts; store prompt snapshots can lag disk; bots fall back to editing memory/*.md by hand.

Notes from local investigation

SQLite stores integrity-check OK; disk not full; agent-data → sand-data symlink fine.
Host shows related brain-docs diagnostics (brain_docs_compensation_failed / brain_docs_channel_config_corrupt).
Box host stamp observed: 332d021b.
Example agent ids: CoS f283b3c0-75c5-41ac-a60b-455ef252740e; also reproduced on Economist and a brand-new Engineer.
Already filed in-app feedback (privacy mode blocked SendFeedback from the bot; filed via Help → Send Feedback).

Workaround
File-append durable facts to memory/profile.md / memory/log/YYYY-MM.md until fixed. Do not recommend Update/Reset Computer as the first fix for this (looks harness/brain-docs side).

Steps to Reproduce

Open any bot (fresh or old).
Ask it to run update_state → target: memory, action: write, short log/note fact.
Observe tool error: brain docs snapshot was cut short before completing.
Confirm the fact is absent from memory/*.md (unless the bot file-appended as a workaround).
Optionally: update_state → target: settings still succeeds on the same bot.

Expected Behavior

Memory write succeeds; fact appears in agent memory / prompt snapshots.

Operating System

MacOS

Version Information

Version: 0.53.0
Release Track: stable
OS: darwin

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. It really helps that you included the exact error, steps, and what you observed right away.

This is a known issue we’re already tracking. It shows up exactly the way you described: memory writes via update_state (target: memory) fail with brain docs snapshot was cut short before completing, while update_state with target: settings and direct file edits work fine. The fact that it happens on both new and old bots is expected for this issue, so it’s not caused by a single overloaded chat or anything in your setup.

Your workaround is spot on. Have the bot write important facts directly into memory/profile.md or memory/log/YYYY-MM.md until this is fixed. You don’t need to run Update / Reset Computer for this, it won’t change anything.

I can’t share a timeline yet, but I’ll post in this thread as soon as there’s an update.

7

Follow-up (2026-09-17 ~10:10 AM America/Los_Angeles): update_state routine create/update also failing

Same Grok Bot / update_state surface as the memory/brain docs issue in this thread, but a different error string.

Agent IDs (reproduced on both)

  • Chief of Staff: f283b3c0-75c5-41ac-a60b-455ef252740e
  • Daily News: b703fc44-a58f-40fd-8fd6-5ecd482e9fd9

What’s failing now

  • update_state · target routine · action create
    Error: Not saved — the routine could not be saved on the server this turn (create failed); try again in a moment.
    Attempted new routine name: News Briefing ship check (schedule 15 9 * * *). Disk staging only under …/automations/news-briefing-ship-check/ — not live on server (update with that folder id → no routine with folder "news-briefing-ship-check" exists).
  • update_state · target routine · action update
    Same save error with (update failed).
    Targeted existing routine: Yesterday fleet brief
    • Server folder id: f46067a6-2734-57e3-a425-47b904b4f11e
    • Disk path folder: yesterday-fleet-brief
    • Attempt: no-op schedule keep 40 8 * * * (still failed)

Daily News also failed 3× the same morning syncing routine folder daily-ai-tech-vc-briefing (display name News Briefing, schedule 30 8 * * *).

Still failing (original memory bug)

  • update_state · target memory on CoS (f283b3c0-…)
    Error: Error: brain docs snapshot was cut short before completing
    Related standing check: folder id memory-write-recovery-check (last run 2026-09-16 10:53:25 AM PT — failed).

Recent success (for bisect)

  • 2026-09-16: CoS successfully created Magok NR compare starts — folder id magok-nr-compare-starts, cron 50 8 25 12 *.
  • 2026-09-16: CoS successfully updated Yesterday fleet brief (f46067a6-2734-57e3-a425-47b904b4f11e).
  • By 2026-09-17 ~10:10 AM PT, create and update both fail with the generic server-save message (not the brain-docs string).

Other live CoS routine folder ids (context)

  • Workspace hygiene: c3c06169-af07-5f7c-a961-b03a458c554f
  • Yesterday fleet brief: f46067a6-2734-57e3-a425-47b904b4f11e
  • Memory write recovery check: memory-write-recovery-check
  • Magok NR compare starts: magok-nr-compare-starts

Impact

Disk edits to automations/*/automation.json still work as workaround, but live harness may not pick them up until server sync succeeds. Blocks new standing routines and prompt updates via update_state.

Ask

Please treat routine create/update save failures as in-scope with the memory/brain docs incident (or confirm if separate). Happy to pull request/turn ids from client logs if you say which field you need.

8

Quite flaky.

image
image892×402 27.2 KB

14

Hey, thanks for the detailed follow-up.

The create, update, delete routine failures you hit on September 17, the message “the routine could not be saved on the server this turn” and the “Deleting failed” dialog, were a separate temporary service outage on our side that morning, roughly from 6:30 to 10:40 Pacific. It affected routines for everyone during that window and was fixed the same day, so it’s not related to the memory issue. Create, update, delete routines should work normally now. If you try again and it fails, let me know and I’ll take another look.

The memory issue itself, update_state with target: memory failing with brain docs snapshot was cut short before completing, is still open and we’re tracking it. There’s no fix yet, and I don’t have a timeline I can share. Your workaround, writing important facts directly to memory/profile.md or memory/log/YYYY-MM.md, is still the right approach for now. Update or Reset Computer isn’t needed and won’t change anything. I’ll reply in the thread once there’s an update.

15

Grok Bot itself just told me the issue is fixed. Awesome!

16

Myself and a colleague both seem to be hitting this issue again as of Sept 25th

Where as my colleague had a relatively complex workflow and routine, I went for something simple - a rule that calculates how many days until Christmas, and a routine that would trigger every morning and tell me how many days to go.

Error (every attempt): Not saved: the routine could not be saved on the server this turn (create failed); try again in a moment.

What I’m trying to create:

  • Name: Christmas countdown
  • Schedule: 10 9 * * * (daily ~9:10 Europe/London)
  • Trigger type: cron via chat (update_state target routine, action create)
  • No confirm card appears — fails before save

Timeline:

  • First failures: ~11:10 BST on 25 Sep 2026
  • Still failing as of ~14:04 BST same day (many retries over ~3 hours)
  • status.cursor.com showed All Systems Operational during this window; today’s Grok Bot incident (computers create/reach/reset, ~05:17–06:51 UTC) was already Resolved before our first failure

Environment:

  • Cursor Team plan
  • Grok Bot desktop 0.58
  • Timezone: Auto Detect (Europe/London)
  • Bot: Grok Bot (server-managed / temporal harness; routines kept on server)
  • Exact create payload class matches the Sep 17 reports (morning daily cron)

What still works:

  • Chat and box Shell work normally
  • Rules can be defined, saved, published and seen by other Team members (so persistence seems to work)
  • update_state memory write succeeds on this bot
  • So this is specific to routine create, not a total update_state outage on my side

Ruled out on my side:

  • Not Start-plan gating (Team plan)
  • Not an old app build (0.58)
  • Not timezone misconfig
  • The Agent Comp was fully updated - no change.
17

Same create failure here, still happening as of 26 Sep ~05:40 IST.

Exact error on every attempt: Not saved: the routine could not be saved on the server this turn (create failed)

Tried:

  • Recreating three GitHub PR listeners (with userAllowlist)
  • A tiny weekday cron probe just to test the save path
  • Resume of the old local copies

All fail. Local paused copies are still on disk from mid-Sep; the live Routines list is empty. Mac app updates didn’t change anything. Status currently shows Grok Bot Degraded / Automations Operational, which matches what others are seeing.

Happy to share more detail if useful.

18

Hey @Matt_Devaney, @Amogh_Tyagi, thanks for the details. There’s an important distinction here.

The original issue in this thread (brain docs snapshot was cut short during memory-write) has been fixed, and the OP confirmed that above. What you’re describing, a crash of the create routine with Not saved: the routine could not be saved on the server this turn (create failed), is a separate issue and not related to memory. I can see that memory-write, rules, chat, and shell work for both of you, and only routine creation fails.

To speed up debugging, a couple questions:

  • The Request ID for a failed create attempt, if Privacy Mode isn’t enabled: in the bot chat, top-right menu > Copy Request ID.
  • @Matt_Devaney, on the same bot, does create fail for any routine, or only for a specific payload? Do update, pause, delete for existing routines work?

So this routine issue doesn’t get lost in a thread about an already-fixed memory bug, please continue in a separate topic. Please create a new thread for your issue.