feat(ai): refresh provider model catalogs on demand - #938
Conversation
📓 Changelog previewThis is what your commits will add to the generated ## [Unreleased]
### Added
- **ai:** Refresh provider model catalogs on demand |
Greptile SummaryThe PR adds permission-checked, principal-aware provider-model refreshes backed by persistent user workspaces, with cache invalidation, lifecycle fencing, local credential import, and frontend progress/error handling. The current-head target-specific import guard aligns the macOS-only import with all of its uses.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| crates/temps-ai-agent-cli/src/service.rs | Principal-scoped workspace model snapshots, cooldown state, and single-flight locks resolve the previously reported cross-user cache reuse. |
| web/src/pages/agent-sandbox/AgentSandboxProviderDetail.tsx | Provider refresh now uses the generated React Query mutation and derives button loading state from isPending. |
| crates/temps-agents/src/services/provider_credential_service.rs | Local credential discovery is bounded and platform-aware; the current-head macOS cfg consistently guards the Duration import and all uses. |
| crates/temps-agents/src/handlers/ai_providers.rs | Adds typed, permission-checked refresh and credential-import endpoints with audit logging and sanitized refresh failures. |
| crates/temps-ai/src/service.rs | Adds provider capability snapshots, refresh policies, caching, invalidation, and refresh coordination used by host and workspace discovery. |
| web/src/lib/ai-provider-catalog-query.ts | Centralizes the generated provider-catalog query options and shared cache identity used across refreshed model consumers. |
Sequence Diagram
sequenceDiagram
participant UI as Provider UI
participant API as Refresh API
participant Cache as Principal Cache
participant WS as User Workspace
participant CLI as Provider CLI
UI->>API: Refresh provider models
API->>API: Check runtime and sandbox permissions
API->>Cache: Lookup principal-scoped refresh state
alt Reusable cached catalog
Cache-->>API: Cached capabilities
else Discovery required
API->>WS: Create or wake persistent workspace
WS->>CLI: Initialize metadata-only discovery
CLI-->>WS: Account-aware model catalog
WS-->>Cache: Store catalog for principal
Cache-->>API: Refreshed capabilities
end
API-->>UI: Typed catalog response
UI->>UI: Update query cache and refresh status
Reviews (6): Last reviewed commit: "feat(ai): refresh provider model catalog..." | Re-trigger Greptile
1efcc7a to
684f849
Compare
|
@greptile-apps please re-review the current head. All previous findings have been addressed with regression coverage. |
52292c4 to
937ad03
Compare
|
@greptile-apps please re-review the current head. The model refresh now creates/wakes the principal-owned persistent global workspace, uses the provider-native Claude initialize catalog, and fail-closes recovered workspace reuse behind a verified process-tree fence. All prior backend, frontend, lifecycle, and security findings have been addressed. |
Discover provider capabilities explicitly instead of spawning CLIs during catalog reads. Cache authoritative results, preserve stale selections safely, and refresh workspace-capable providers through isolated credential relays. Signed-off-by: David Viejo <dviejo@kfs.es>
937ad03 to
11c19bd
Compare
|
@greptile-apps please re-review current head 11c19bd. The only delta after your prior 5/5 is a target-specific cfg on the macOS-only Duration import, fixing the Linux all-features Clippy job. |
Summary
temps-agent-runtimeWhy
Provider model lists are account-aware and can change independently of Temps. Claude Code exposes the usable catalog only after its authenticated CLI initializes, so a static host-side list cannot be authoritative. Previously, Temps advertised invented identifiers such as
claude-sonnet-5; those values could be rejected by the installed harness.The refresh flow now asks the real CLI in the user's workspace. For a global user-owned chat, Temps creates or wakes that user's persistent workspace automatically. It does not require the user to manually start a sandbox, and it does not treat an unavailable sandbox as a successful empty workspace.
Behavior
global-user-{principal}through the normal workspace and sandbox servicesSandboxService, preserving its volume and synchronizing registry/database stateEvidence
Backend
The real process regression also verified that a TERM-resistant parent and child are escalated and removed:
cargo test --lib -p temps-agents strict_fence_kills -- --nocaptureFrontend
bun test src/components/ai/DebugChatPanel.test.ts src/components/ai/chat-runtime-options.test.ts bunx tsc --noEmitBrowser
agent-browserexercised the generated client against the exact branch server in isolated dev slot 33:Sandbox starting/recoveringRepository gates
Security
SandboxesWriteandSandboxesExecReview