Skip to content

Fix missing Continue button for API-triggered Claude Code cloud runs (REMOTE-2206)#13903

Draft
seemeroland wants to merge 1 commit into
masterfrom
oz-agent/REMOTE-2206
Draft

Fix missing Continue button for API-triggered Claude Code cloud runs (REMOTE-2206)#13903
seemeroland wants to merge 1 commit into
masterfrom
oz-agent/REMOTE-2206

Conversation

@seemeroland

Copy link
Copy Markdown
Contributor

Description

Fixes the missing "Continue" button for Claude Code cloud runs started via the Oz REST API after sandbox idle timeout.

Root cause: For Claude Code runs started via API (not from the Warp desktop app), no local Oz conversation is ever created. This means ConversationServerTokenAssigned never fires, and get_server_conversation_metadata_by_server_token always returns None. The existing fallback checks task.creator.uid == current_user_uid, but for API-triggered runs created with service-account API keys, these UIDs can differ — leaving access = Unknown and the tombstone resolver returning Tombstone { cta: None } (no Continue button).

Fix:

  1. BlocklistAIHistoryModel::fetch_server_conversation_metadata_if_needed — new method that starts a background list_ai_conversation_metadata request for the conversation token when no metadata is cached. On success it stores the result in all_conversations_metadata and emits UpdatedConversationMetadata. Concurrent calls for the same token are no-ops while a fetch is in-flight.

  2. TerminalView::maybe_insert_tombstone_for_non_running_shared_ambient_task — now calls the new method whenever the task has a conversation_id but no server metadata is in the model. When the fetch completes, UpdatedConversationMetadata re-triggers this function, which re-resolves the tombstone CTA using the server-supplied access grants — correctly showing the "Continue" button for run owners.

Linked Issue

  • REMOTE-2206: AG1: 'Continue' button missing for Claude Code cloud runs started via API after sandbox idle timeout

Testing

Added api_triggered_third_party_run_shows_continue_cta_after_metadata_fetch — a unit test that:

  1. Creates a Claude Code task whose creator.uid is a service-account UID (≠ current user's Firebase UID), reproducing the API-trigger scenario.
  2. Verifies the initial state returns MissingServerConversationMetadata (no CTA).
  3. Simulates the background fetch by inserting server metadata (with the current user as space owner) via the new insert_server_metadata_for_test test helper.
  4. Verifies the resolver now returns Tombstone { cta: Some(ContinueInCloud { .. }) }.
  • I have manually tested my changes locally with ./script/run

Conversation: https://staging.warp.dev/conversation/aac448c1-51c3-47a4-98bd-390462e16d56
Run: https://oz.staging.warp.dev/runs/019f7177-66c8-7b02-83f8-3870a6344b83

This PR was generated with Oz.

For Claude Code runs started via the Oz REST API (not the Warp desktop
app), no local Oz conversation is ever created, so ConversationServerTokenAssigned
never fires and get_server_conversation_metadata_by_server_token returns None.

The existing fallback (task_creator_access) only grants Edit access when
task.creator.uid matches the logged-in Firebase UID, but API runs can be
created by service-account API keys whose UID differs from the viewer's
Firebase UID. This leaves access as Unknown, so the tombstone resolver
falls back to Tombstone { cta: None } — the 'Continue' button never
appears after sandbox idle timeout.

Fix: in BlocklistAIHistoryModel, add
fetch_server_conversation_metadata_if_needed. This kicks off a background
list_ai_conversation_metadata request and stores the result in
all_conversations_metadata keyed by the server token. On success it emits
UpdatedConversationMetadata, which re-triggers
maybe_insert_tombstone_for_non_running_shared_ambient_task in TerminalView.
The tombstone then re-resolves via the server metadata path (instead of
the creator-UID fallback), using the conversation's actual access grants to
show the Continue CTA.

Call this from maybe_insert_tombstone_for_non_running_shared_ambient_task
whenever the task has a conversation_id but no metadata in the model.
Deduplication prevents redundant in-flight fetches.

Add a test that verifies the end-to-end fix: a Claude Code run created by
a service-account API key (creator UID ≠ current user) initially returns
MissingServerConversationMetadata, then shows ContinueInCloud once
the fetched metadata (with the current user as space owner) is stored.

Co-Authored-By: Oz <oz-agent@warp.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant