CLI's (Codex, Gemini, Claude) have been added as provider.

[tr-varlg]

Selam abi, twitter'dan yazmıştım CLI kullanımıyla alakalı.

Ben Codex'ten destek alarak içeri entegre etmeye çalıştım. Şimdilik bende iş görür durumda ama geri kalan API Key kısımlarını da test edemedim. Umarım fayda sağlar :)

[ersinkoc]

Review: CLI Providers

The architectural idea of centralizing provider creation into model-execution.ts is solid, but there are several blocking issues.

Critical — Must Fix

1. Turkish UI strings — Project rule: everything must be in English. Multiple user-facing strings in ProvidersTab.tsx are in Turkish (toast messages, banners, removal modal). All must be translated.

2. Reduced NATIVE_PROVIDERS set — createSingleRuntimeProvider() only checks for openai, anthropic, google. The existing code supports 10 native providers (deepseek, groq, mistral, xai, together, fireworks, perplexity etc.). This silently regresses all of those to the openai provider type, losing provider-specific SDK features.

3. Fallback model parameter dropped — createRuntimeProvider() ignores the fallback model entirely. The original code in agent-service.ts used fallback.model and had an onFallback observability callback. Both are lost.

High

4. stream() is not actually streaming — collectStreamingProcess() buffers the entire output, then yields all chunks at once. Streaming consumers will appear to hang until CLI completes.

5. Provider ID collision — gemini-cli already exists as a BuiltinCodingAgentProvider in coding-agent-service.ts. Adding it as a chat runtime provider with the same ID creates ambiguity.

6. process.cwd() as working directory — CLI completions run in the server's working directory, potentially exposing server-side files. The coding agent service has validateCwd() for this purpose.

Medium

7. No tests for model-execution.ts — 564 lines of new core logic with zero unit tests. The module is fully mocked in other test files, so none of its behavior is actually verified.

8. apiKey ?? '' — Passing empty string API keys will cause 401s at the API level rather than failing fast. Consider making the field optional or handling the no-key case explicitly.

Suggestion

Consider splitting this into two PRs:

1. Refactor: Centralize provider creation logic (pure refactor, no new features)
2. Feature: Add CLI runtime providers on top of the clean foundation

This would make it much easier to verify the refactor doesn't regress existing behavior.

Thanks for the contribution! The centralization direction is right — just needs these issues addressed.