[Bug]: Edit from here is hidden on Grok and Antigravity and offered on Muse, unlike what the server accepts#30137

opened1d agobyEEntrpi

What happens

Whether a client offers Edit from here comes from a hand-set supportsConversationRollback flag in the provider status, while the server decides from the adapter capabilities (ensureRollback in CommandPolicy.ts). The two disagree:

  • Grok (provider-grok/src/server/status.ts) and Antigravity (AntigravityProvider.ts) set the flag to false, so the web hides Edit from here, although the server accepts the rollback.
  • Muse sets no flag, so the web shows Edit from here, and the server refuses it because Muse cannot roll back.

Steps to reproduce (main cefb544af3)

  1. Open a finished Grok or Antigravity thread on web. No sent prompt offers Edit from here.
  2. Open a finished Muse thread. Edit from here is offered, and choosing it fails.

Expected

Edit from here is offered exactly where the server accepts the rollback, from one rule, so a new adapter cannot drift.

I have a fix that derives the status flag from the adapter capabilities with the same predicate the policy enforces, and removes the hand-set flags. It builds on the fix for #30136, which lets ACP rollbacks through the policy. I can open a PR if you want one.

Synced from GitHub

The fix is on our fork as one commit on top of the #30136 fix: c8d60f4 (compare).

ProviderRegistry sets supportsConversationRollback from the adapter capabilities with canRewindConversation, the predicate ensureRollback uses, and the hand-set flags in Cursor, Grok and Antigravity are gone. The new test in ProviderRegistry.test.ts covers an ACP provider (rewinds into a fresh session) and Cursor (cannot rewind); the existing Codex snapshot expectations cover native rewind. Happy to open it as a PR if you want it.