🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

const agentRuntimeOverride = normalizeOptionalString(
  params.getActiveSessionEntry()?.agentRuntimeOverride,
);
const cliExecutionProvider =
  resolveCliRuntimeExecutionProvider({
    provider,
    cfg: runtimeConfig,
    agentId: params.followupRun.run.agentId,
    runtimeOverride: agentRuntimeOverride,
  }) ?? provider;

if (isCliProvider(cliExecutionProvider, runtimeConfig)) {
  ...
  const result = await runCliAgent({ provider: cliExecutionProvider, ... });
}

const wantsCli = isCliProvider(cliExecutionProvider, runtimeConfig);
if (wantsCli && !params.followupRun.run.senderIsOwner) {
  throw new Error("CLI backends are restricted to owners/admins");
}

...(agentRuntimeOverride && agentRuntimeOverride !== "auto" && agentRuntimeOverride !== "default"
  ? { agentHarnessId: agentRuntimeOverride }
  : {}),

if (!agentHarnessId?.trim()) return undefined;
const runtime = normalizeEmbeddedAgentRuntime(agentHarnessId);
if (runtime === "auto") return undefined;
return { runtime, fallback: "none" };

if (policy.fallback === "none") {
  throw new Error(
    `Requested agent harness "${runtime}" is not registered and PI fallback is disabled.`,
  );
}

function resolvePinnedAgentHarnessPolicy(agentHarnessId?: string): AgentHarnessPolicy | undefined {
  const raw = agentHarnessId?.trim();
  if (!raw) return undefined;
  const runtime = normalizeEmbeddedAgentRuntime(raw);
  if (runtime === "auto") return undefined;
  ​// Allow PI fallback for session overrides to avoid bricking sessions when a runtime is unavailable
  return { runtime, fallback: "pi" };
}

Analyzed PR: #71259 at commit f5c687e

_{Last updated on: 2026-04-24T23:57:36Z}

Greptile Summary

This PR reverses the codex-only PR #71193 and generalises the model/runtime split to Anthropic Claude CLI and Google Gemini CLI as well: canonical provider/model refs are kept for model selection while execution backend is recorded separately in embeddedHarness.runtime. It introduces model-runtime-aliases.ts as the central registry, extends the Discord model picker with a runtime selector row, and propagates --runtime through inline directives and session state.

Confidence Score: 5/5

Safe to merge; both remaining findings are minor defensive/style issues that don't affect current runtime behaviour.

The core migration logic, CLI routing, session-override persistence, and Discord picker changes are all well-tested. The only findings are a missing .startsWith guard (currently harmless given how the constant is defined) and a duplicate config label.

extensions/anthropic/register.runtime.ts (defensive coding), src/config/schema.labels.ts (duplicate label)

This is a comment left during a code review.
Path: extensions/anthropic/register.runtime.ts
Line: 81-83

Comment:
`CLAUDE_CLI_CANONICAL_DEFAULT_MODEL_REF` slices `CLAUDE_CLI_DEFAULT_MODEL_REF` without first verifying it starts with `${CLAUDE_CLI_BACKEND_ID}/`, whereas the parallel `CLAUDE_CLI_CANONICAL_ALLOWLIST_REFS` computation directly above it correctly guards with `.startsWith(...)`. If `CLAUDE_CLI_DEFAULT_MODEL_REF` were ever changed to a canonical `anthropic/...` form, the slice would produce `anthropic/ic/claude-opus-4-7` or similar garbage silently.

```suggestion
const CLAUDE_CLI_CANONICAL_DEFAULT_MODEL_REF = CLAUDE_CLI_DEFAULT_MODEL_REF.startsWith(
  `${CLAUDE_CLI_BACKEND_ID}/`,
)
  ? `anthropic/${CLAUDE_CLI_DEFAULT_MODEL_REF.slice(CLAUDE_CLI_BACKEND_ID.length + 1)}`
  : CLAUDE_CLI_DEFAULT_MODEL_REF;
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/config/schema.labels.ts
Line: 75-76

Comment:
Both `agents.defaults.embeddedHarness` (the container object) and `agents.defaults.embeddedHarness.runtime` (the leaf field) are now labeled identically as `"Default Agent Runtime"`. In any flat config UI or help output that lists both entries, the two are indistinguishable. The old names ("Default Embedded Harness" / "Default Embedded Harness Runtime") were distinct; something like `"Default Agent Harness"` for the parent would avoid the collision.

```suggestion
  "agents.defaults.embeddedHarness": "Default Agent Harness",
  "agents.defaults.embeddedHarness.runtime": "Default Agent Runtime",
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(models): reverse codex-only runtime ..." | Re-trigger Greptile}

Codex review: do not merge yet.

I agree with the direction of splitting canonical provider/model selection from runtime selection, but the current PR still has a real trust-boundary bug around /model --runtime.

Blocking finding:

• src/auto-reply/reply/directive-handling.persist.ts:205 persists directives.rawModelRuntime from chat text directly into sessionEntry.agentRuntimeOverride for any parsed /model ... --runtime ... directive.
• src/auto-reply/reply/agent-runner-execution.ts:936 then reads that session value and uses it to affect runtime selection. It can select a CLI execution provider through resolveCliRuntimeExecutionProvider(...), and for embedded runs it passes the same value through as agentHarnessId at src/auto-reply/reply/agent-runner-execution.ts:1106.
• src/auto-reply/model.ts:18 accepts broad runtime strings ([A-Za-z0-9_.:-]+). I do not see an allowlist/permission check at persistence time tying the requested runtime to the current provider/model, configured runtime choices, or sender authority.

This is not just cosmetic. Runtime selection changes execution backend semantics. A chat user who is allowed to send model directives should not automatically be allowed to persist arbitrary runtime/harness overrides. The fix should validate the requested runtime before storing it, probably against the same runtime choices exposed to the picker plus configured agent policy, and reject/ignore unknown or unauthorized values. The execution path should also defensively refuse an unrecognized persisted override instead of treating it as a pinned harness id.

Smaller cleanup findings, non-blocking after the runtime gate is fixed:

• extensions/anthropic/register.runtime.ts:81: CLAUDE_CLI_CANONICAL_DEFAULT_MODEL_REF slices CLAUDE_CLI_DEFAULT_MODEL_REF as if it always starts with claude-cli/. The allowlist mapping above has the correct startsWith guard; the default should use the same pattern to avoid silently producing a bad ref if the constant changes shape later.
• src/config/schema.labels.ts:75: agents.defaults.embeddedHarness and agents.defaults.embeddedHarness.runtime both label as Default Agent Runtime, which makes flat config/help output ambiguous. Keep the parent distinct, e.g. Default Agent Harness, and the leaf as Default Agent Runtime.

Also current checks are still red (check, check-test-types, check-additional, checks-node-core-fast-support / related). Even if some are stale, this needs a fresh green run after the runtime validation fix.