Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

apps/controller/src/services/model-provider-service.ts (1)

498-523: Consider supporting auth headers for secured Ollama instances.

The verification request doesn't include any authentication headers, but input.apiKey is available. If a user configures a secured Ollama instance (e.g., behind a reverse proxy with API key auth), the verification will fail even with valid credentials.

Consider adding optional auth support:

💡 Suggested enhancement

       if (providerId === "ollama") {
+        const headers: Record<string, string> = {};
+        if (input.apiKey && input.apiKey !== OLLAMA_DUMMY_API_KEY) {
+          headers.Authorization = `Bearer ${input.apiKey}`;
+        }
         const response = await fetch(
           buildProviderUrl(
             input.baseUrl ?? PROVIDER_BASE_URLS[providerId] ?? null,
             "/api/tags",
           ) ?? verifyUrl,
           {
+            headers: Object.keys(headers).length > 0 ? headers : undefined,
             signal: AbortSignal.timeout(10000),
           },
         );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/src/services/model-provider-service.ts` around lines 498 -
523, The Ollama verification branch (providerId === "ollama" inside
validate/check routine) currently calls fetch(buildProviderUrl(...) ??
verifyUrl, ...) without any auth headers; update the request to include
authentication when input.apiKey is present—add an Authorization (e.g., Bearer)
or X-API-Key header as appropriate to the fetch options so secured Ollama
instances behind API-key auth can be validated; keep using buildProviderUrl and
preserve the AbortSignal.timeout behavior and error handling.

apps/web/src/pages/models.tsx (1)

1352-1354: Consider extracting the placeholder constant.

The hardcoded "ollama-local" string is used as a dummy API key for Ollama (which doesn't require authentication). This value propagates to the backend and database. Consider extracting it to a named constant for clarity and to avoid magic strings.

💡 Suggested refactor

+const OLLAMA_PLACEHOLDER_KEY = "ollama-local";
+
 function ByokProviderDetail({
   // ...
 }) {
   // ...
   const isOllama = providerId === "ollama";
   const hostBridge = getModelsHostInvokeBridge();
-  const effectiveApiKey = isOllama ? "ollama-local" : apiKey;
+  const effectiveApiKey = isOllama ? OLLAMA_PLACEHOLDER_KEY : apiKey;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/src/pages/models.tsx` around lines 1352 - 1354, Replace the magic
string "ollama-local" used when computing effectiveApiKey with a named constant
(e.g., OLLAMA_DUMMY_API_KEY or OLLAMA_LOCAL_API_KEY); update the code that sets
effectiveApiKey (the isOllama check and assignment) to use that constant and
move the constant to an appropriate scope/file (same module or shared constants)
so it’s clear this is a deliberate dummy key and can be reused wherever isOllama
or effectiveApiKey logic is referenced.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

apps/controller/src/runtime/openclaw-process.ts (1)

22-38: Consider extracting findWorkspaceRoot() to a shared utility.

This function is duplicated verbatim in apps/controller/src/services/model-provider-service.ts (lines 181-194). Both files use identical logic to discover the monorepo root for openclaw entry path resolution.

Extracting this to a shared module (e.g., lib/workspace.ts or lib/paths.ts) would reduce duplication and ensure both call sites stay in sync.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/controller/src/runtime/openclaw-process.ts` around lines 22 - 38,
Extract the duplicated findWorkspaceRoot logic into a shared utility module
(e.g., create lib/workspace.ts or lib/paths.ts) that exports a single function
named findWorkspaceRoot(startDir: string): string | null; replace the inline
implementations in openclaw-process.ts and model-provider-service.ts with
imports from that new module and call the exported findWorkspaceRoot to preserve
behavior; ensure the new module imports path and existsSync and re-exports the
function signature unchanged so both call sites (findWorkspaceRoot in
openclaw-process.ts and the duplicate in model-provider-service.ts) require no
other changes.

tests/desktop/openclaw-config-compiler.test.ts (1)

292-292: Misleading test name: "native ollama API" vs "openai-completions".

The test name suggests Ollama is compiled with its "native" API, but the assertion expects api: "openai-completions" (Line 316). While Ollama does expose an OpenAI-compatible endpoint, calling it "native" may confuse future maintainers. Consider a clearer name:

-  it("compiles ollama providers with the native ollama API", () => {
+  it("compiles ollama providers using the openai-completions API", () => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/desktop/openclaw-config-compiler.test.ts` at line 292, The test name is
misleading: change the "it" description that currently reads 'compiles ollama
providers with the native ollama API' to clearly indicate the OpenAI-compatible
endpoint (e.g., 'compiles ollama providers with the OpenAI-compatible API') or
alternatively update the expectation to match true native behavior; locate the
test starting with it("compiles ollama providers with the native ollama API", ()
=> { and adjust the string to reference "openai-completions" (or make the
assertion match the native Ollama API) so the test name and the assertion api:
"openai-completions" are consistent.

apps/web/src/pages/models.tsx (2)

2177-2196: Consider extracting the verification result display.

This JSX block (lines 2177-2196) duplicates the verification feedback from lines 2120-2139. Consider extracting to a small component or helper to reduce duplication.

💡 Example extraction

function VerifyResultFeedback({
  result,
  t,
}: {
  result: { valid: boolean; models?: string[]; error?: string } | undefined;
  t: (key: string, options?: Record<string, unknown>) => string;
}) {
  if (!result) return null;
  return (
    <div
      className={cn(
        "mt-1.5 text-[10px]",
        result.valid ? "text-emerald-600" : "text-red-500",
      )}
    >
      {result.valid
        ? t("models.byok.keyValid", { count: result.models?.length ?? 0 })
        : t("models.byok.keyInvalid", {
            error: result.error ?? t("models.byok.keyInvalidUnknown"),
          })}
    </div>
  );
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/src/pages/models.tsx` around lines 2177 - 2196, Extract the
duplicated JSX that renders verification feedback into a small reusable
component (e.g., VerifyResultFeedback) and use it in both places where the block
currently appears; the component should accept the verify result
(verifyMutation.data or similar) and the translation function t, return null if
no result, apply the same cn styling logic ("mt-1.5 text-[10px]" + result.valid
? "text-emerald-600" : "text-red-500"), and render the same translation calls
(t("models.byok.keyValid", { count: result.models?.length ?? 0 }) or
t("models.byok.keyInvalid", { error: result.error ??
t("models.byok.keyInvalidUnknown") })) so both instances (the JSX using
verifyMutation and the other duplicated block) simply render
<VerifyResultFeedback result={verifyMutation.data} t={t} />.

---

1543-1573: Consider adding error feedback for refreshModelsMutation.

The mutation throws on verification failure but lacks onError/onSuccess handlers to show toast feedback to the user. Other mutations in this file (e.g., saveMutation, verifyMutation) handle errors more gracefully or show success feedback.

💡 Suggested improvement

   const refreshModelsMutation = useMutation({
     mutationFn: async () => {
       // ... existing code ...
       return models;
     },
+    onSuccess: () => {
+      toast.success(t("models.byok.refreshSuccess"));
+    },
+    onError: (error) => {
+      toast.error(
+        error instanceof Error
+          ? error.message
+          : t("models.byok.refreshFailed"),
+      );
+    },
   });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/web/src/pages/models.tsx` around lines 1543 - 1573, The
refreshModelsMutation currently throws on verification failure but has no
onError/onSuccess handlers to surface toast feedback; update the useMutation
call for refreshModelsMutation to add onSuccess and onError callbacks that (1)
show success toasts when models are loaded (using the returned models and e.g.,
t messages), call setVerifiedModels as needed, and invalidate queries via
queryClient.invalidateQueries (["providers"], ["models"]) after saveProvider,
and (2) show error toasts when verifyApiKey returns invalid or when saveProvider
fails (capture and log the error), ensuring you reference refreshModelsMutation,
verifyApiKey, saveProvider, setVerifiedModels, and queryClient.invalidateQueries
in the handlers.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".