I already have support ticket T-G64842 open for this issue.
My Grok Bot persistent computer appears to have been reprovisioned into a new computer context without me initiating Update, Recover, or Reset.
The original computer had been running since Sep 17. On Oct 5, a second context appeared with a different boot ID and different filesystem/runtime state.
For several hours, the old Sep 17 context and the new Oct 5 context appeared to coexist through different access paths. During that overlap, work and filesystem changes were still occurring on the older context.
Over time, Grok Bot sessions converged on the newer Oct 5 context. The older Sep 17 context then became unreachable through its previously working SSH/Tailscale path.
The important problem is that the newer Oct 5 context does not contain all of the latest data/state that existed on the Sep 17 context before it became unreachable.
This looks like a reprovisioning or migration where the replacement computer may have been created from an earlier snapshot, while the original computer remained writable for some period afterward.
I did not run:
Update
Recover
Reset
a new Tailscale enrollment
I also observed repeated persistent-storage manifest concurrent-write conflicts while both contexts appeared to exist, which may indicate that both contexts were interacting with the same logical persistent storage identity.
At this point, all observable Grok Bot sessions appear to be routed to the newer Oct 5 context, while the previous Sep 17 context is no longer reachable.
Steps to Reproduce
I did not intentionally trigger this, so I do not have a deliberate reproduction procedure. This is the sequence I observed:
Use a persistent Grok Bot computer normally over an extended period. Mine had been running since Sep 17 with persistent filesystem state and existing SSH/Tailscale operator access.
Without running Update, Recover, or Reset, a new Grok Bot computer context appears with a different boot ID and different filesystem/runtime state.
The original and new contexts remain observable at the same time for a period.
Continue normal work on the original context while it is still active.
Over several hours, Grok Bot sessions begin routing to the newer context.
Eventually, all observable Grok Bot sessions are routed to the newer context.
The original context becomes unreachable through its previously working SSH/Tailscale connection.
Compare the newer context with the final state of the original context.
Recent filesystem/runtime changes made on the original context before the cutover are missing from the newer context.
Support ticket for the affected account: T-G64842.
Expected Behavior
If Grok Bot needs to reprovision or replace a persistent computer, the latest persistent state should be fully synchronized before routing moves to the replacement context.
The old and new contexts should not remain independently writable in a way that allows their state to diverge.
A safe handoff should do one of the following:
freeze the old context before creating/finalizing the replacement,
synchronize all changes made before cutover,
or clearly warn the user that the replacement may restore an earlier snapshot and that recent state may be lost.
Existing persistent operator state such as SSH/Tailscale should either remain valid across a normal reprovisioning or there should be a documented, safe re-enrollment procedure after the new context is confirmed as canonical.
The user should not silently end up on a replacement computer containing older state while the previously active computer becomes unreachable.
Operating System
MacOS
Version Information
N/A — Grok Bot Computer issue; not specific to an IDE, CLI, or iOS app version.
As of now, both contexts are simultaneously observable: Grok Bot sessions are still routed to the Oct 5 context, while the existing Tailscale/OpenSSH endpoint has recovered and reaches the original Sep 17 boot with its original runtime state intact.
Hey, thanks for the detailed report and for sharing the ticket number. What you’re describing matches what we’re seeing on our side too. It’s not related to your setup, and you didn’t actually run Update, Recover, or Reset.
Quick summary: your computer got an automatic recreate that didn’t finish cleanly. Because of that, the original and the new context were running at the same time for a while, and the new one came up from an incomplete copy. That explains both the missing data and the manifest conflicts you noticed.
A couple important things to do right now:
Don’t click Update, Recover, or Reset, and don’t do a second Tailscale enrollment on the new (Oct 5) context. Those actions might overwrite the exact data we’re trying to recover.
You said the original Sep 17 endpoint is accessible again over Tailscale and SSH with its state intact, that’s great. While it’s still accessible, I’d recommend copying the most important and most recent files from it to a safe place locally as a backup. This is safe and won’t trigger another recreate.
I’ve already passed this to the team so we can preserve the original context and move over the missing data.
To speed things up, could you share:
which folders or files are most critical for you, exact paths would be best
whether you created anything important on the new (Oct 5) context after switching that we should also preserve
Let me know how the copying goes, and we’ll reply here once we have an update.
Hi, Dean. Thank you for investigating and explaining what happened.
We’re currently backing up the sessions and related application state that would be difficult to recreate or restore. I’ll let you know once the backup is complete.
After I confirm completion, would it be possible to fully wipe and reprovision the cloud computer, returning it to a clean, initial state? We would prefer to rebuild the environment ourselves rather than migrate the existing installation. It’s also okay if this requires deleting the existing bot and starting with a new one.
Recently, we’ve seen instability during background updates, including large increases in disk usage and failed updates. Given those issues and this incident, we’d like to make a fresh start with a completely clean environment.
For now, please preserve both contexts and do not delete, reset, or reinitialize either one until I explicitly confirm that the backup is complete and we’re ready to proceed.
Please let us know whether this clean-start approach is possible and whether there is anything else we should preserve beforehand. Thank you for your help.
The backup is now complete. Could you confirm whether a full clean reset or reprovisioning is possible, as requested above? We’re ready on our side and would prefer to rebuild the environment ourselves. Thank you for your help.
Hey @monni, to keep everything in one place, we’ll handle your clean reset request on your email ticket, and a teammate will follow up with you there. Until then, please hold off on Update, Recover, and Reset.
Following up on your note that the clean reset would be handled on the email ticket (T-G64842) and that a teammate would contact us there.
Our backup has been complete since Oct 5, and we confirmed readiness again on Oct 6. As of Oct 7 (JST), we have not received any follow-up email on the ticket, and the computer is still on the original Sep 17 context with no clean install started.
Could you please check the status of T-G64842 and either:
confirm when the clean reset / reprovisioning will begin, or
tell us if anything else is needed from our side before you proceed?
We are continuing to hold off on Update, Recover, and Reset as requested. Thank you.
Thanks for replacing the computer. Before we begin rebuilding it, could you confirm the scope of the reset?
The new computer still shows application icons and other signs of the previous setup, so it doesn’t appear to be a completely clean default environment from our side.
What we requested was a fresh environment without our previously installed applications, settings, or user data. Could you confirm whether any part of the old home directory or application state was carried over to this new computer?
Thanks. I checked the replacement computer and confirmed that the system layer appears fresh, but /home/box has been restored from the previous environment, including previous application state and credentials.
Could you please confirm two things:
Is this restored-home state the intended final replacement?
Am I now clear to begin rebuilding the environment, including a fresh Tailscale enrollment, or should we still avoid Update / Recover / Reset / Tailscale registration?
Since we haven’t received a response, we’ll proceed on the assumption that this is the final replacement computer and begin rebuilding the environment around it.
We will treat the carried-over home data and credentials as stale and will not rely on them. We also won’t use Update, Recover, or Reset.
If this is not the intended final state, please let us know.