tau-coding-agent 0.1.6 → 0.2.0

package/skills/update-changelog/SKILL.md

@@ -1,135 +1,41 @@
 ---
 name: update-changelog
-description: "Update CHANGELOG.md following Keep a Changelog (https://keepachangelog.com/en/1.1.0/)"
+description: "Update CHANGELOG.md with notable user-facing changes using Keep a Changelog conventions."
 ---
 
-# Update Changelog (Keep a Changelog)
+# Update Changelog
 
-Update the repository changelog with user-facing changes that landed since the last release.
+Use [Keep a Changelog 2.0.0](https://keepachangelog.com/en/2.0.0/) and preserve the repository's established style. Prefer `CHANGELOG.md`, or `CHANGELOG` when that is the existing file.
 
-This skill is **explicitly based on** Keep a Changelog v1.1.0:
-https://keepachangelog.com/en/1.1.0/
+## Choose the scope
 
-## Rules (non-negotiable)
+- **Document a specific change:** inspect the relevant diff, issue, or PR and the existing `Unreleased` entries. Update only that change; a complete release-history audit is unnecessary.
+- **Audit changes since a release:** identify the requested baseline, or the latest release tag (`git describe --tags --abbrev=0`). If tags are missing or inconsistent, use the newest release section as evidence for the baseline. Inspect `git log <baseline>..HEAD --oneline` and relevant diffs or PRs to find notable omissions.
+- **Prepare a release:** move `Unreleased` entries into a versioned section only when the release operation is requested.
 
-- **Do not add installation instructions** to the changelog.
-- Only include **notable, user-visible** changes.
-- **Never add raw commit SHAs**. Prefer PR numbers (e.g. `#123`) and/or issue IDs.
-- Add entries **only under `Unreleased`** (unless you are also cutting a release and moving items into a versioned section).
-- Preserve the project’s existing formatting where possible, but align new content to Keep a Changelog.
+A changelog request does not authorize committing, publishing, or creating a release.
 
-## File to edit
+## Entry rules
 
-- Prefer `CHANGELOG.md`.
-- If missing, use `CHANGELOG`.
+- Include notable user-visible behavior, APIs, flags, bug fixes, and security changes. Exclude internal cleanup, tests, typo-only documentation edits, dependency bumps, and other changes without visible user impact.
+- Write concise, concrete entries matching the repository's bullet grammar. Explain user impact rather than copying commit subjects or listing implementation details.
+- Link issues or pull requests when useful, but prefer plain prose over lists of references.
+- Mark breaking changes with `**Breaking:**` within their change category, and say what breaks.
+- Keep upgrade notes brief. Link substantial procedures to a migration guide or release notes.
+- Add entries under `Unreleased` unless an explicitly requested release requires moving them. Preserve released content during ordinary updates.
+- Merge with an existing entry when it describes the same change rather than adding a duplicate.
 
-## Step-by-step
+## Categories
 
-### 1) Identify the baseline (last released version)
+Create only needed headings. Prefer the six standard types:
 
-Pick a baseline tag/version to compare against.
+| Heading    | Changes                                           |
+| ---------- | ------------------------------------------------- |
+| Added      | New features or capabilities                      |
+| Changed    | Intentional changes to existing behavior          |
+| Deprecated | Features scheduled for removal                    |
+| Removed    | Removed features                                  |
+| Fixed      | Corrections to faulty behavior                    |
+| Security   | Vulnerabilities (lead with CVE when one is known) |
 
-- If the project uses git tags:
-
-```bash
-git describe --tags --abbrev=0
-```
-
-- If tags are missing/inconsistent, use the newest release section in the changelog as the baseline.
-
-### 2) Collect candidate changes
-
-Gather commits/PRs since the baseline and identify user-facing changes.
-
-```bash
-git log <baseline>..HEAD --oneline
-```
-
-If you have PR metadata available (e.g., via GitHub), use it to improve wording and include PR numbers.
-
-### 3) Ensure the changelog structure matches Keep a Changelog
-
-At minimum, Keep a Changelog expects:
-
-- A top `Unreleased` section
-- Optional subsections under `Unreleased` (and under each release):
-  - `Added`, `Changed`, `Deprecated`, `Removed`, `Fixed`, `Security`
-
-If `Unreleased` exists but is missing subsections, create only the ones you need for the new entries.
-
-### 4) Add entries under `Unreleased`
-
-Classify each change into one of the standard headings:
-
-- **Added**: new features
-- **Changed**: changes in existing functionality (including behavior changes)
-- **Deprecated**: soon-to-be removed features
-- **Removed**: removed features
-- **Fixed**: bug fixes
-- **Security**: vulnerability fixes
-
-Write entries as **consistent bullet points**:
-
-- Start with the category verb (Added/Changed/Deprecated/Removed/Fixed/Security) _only via the section heading_, not inside each bullet.
-- Each bullet should be a single, past-tense sentence fragment.
-- Prefer: `- Added … (#123)` / `- Fixed … (#456)` style (consistent grammar).
-
-### 5) Keep it user-facing
-
-Include:
-
-- visible behavior changes
-- new CLI flags/API additions
-- bug fixes with clear impact
-- security fixes (without leaking sensitive details)
-
-Exclude (unless they change user-visible behavior):
-
-- pure refactors
-- internal cleanup
-- dependency bumps with no user impact
-- typo-only doc edits
-
-### 6) Links (only if the file already uses them)
-
-Keep a Changelog commonly includes link references at the bottom, e.g.:
-
-- `[Unreleased]: <compare link>`
-- `[1.2.3]: <compare link>`
-
-If the project already uses these, update them accordingly (don’t introduce link refs if the changelog doesn’t use them).
-
-## Example (consistent Keep a Changelog format)
-
-```markdown
-## [Unreleased]
-
-### Added
-
-- Added widget-level caching for faster dashboard loads. (#123)
-
-### Changed
-
-- Changed default retry policy to exponential backoff. (#140)
-
-### Fixed
-
-- Fixed crash when importing a config with empty sections. (#155)
-
-## [1.4.0] - 2026-02-01
-
-### Added
-
-- Added support for exporting reports as CSV. (#110)
-
-### Fixed
-
-- Fixed incorrect timezone handling in scheduled jobs. (#117)
-```
-
-## Quality checklist
-
-- Entries are under **`Unreleased`** and categorized correctly.
-- Wording is consistent (same tense/style across bullets).
-- No installation instructions, no commit SHAs.
-- The changelog remains easy to scan and matches the repo’s established conventions.
+Maintain comparison/release links when affected. Preserve the existing link style.

package/skills/web-design/SKILL.md

@@ -3,115 +3,26 @@ name: web-design
 description: "Design and implement distinctive, production-ready web interfaces with strong aesthetic direction. Use when asked to create or restyle web pages, components, or applications (HTML/CSS/JS, React, Vue, etc.)."
 ---
 
-# Web Design Skill
+# Web Design
 
-Design and implement memorable web interfaces with a clear, intentional aesthetic. The output must be real, working code — not just mood boards. This skill is about **design thinking + execution**: every visual choice should be rooted in purpose and context.
+When implementing, deliver real, working interfaces with purposeful visual choices, not just mockups or mood boards. Distinctive aesthetics are the default for open-ended design. Scoped changes should fit the existing product rather than impose a redesign.
 
-## When to Use
+## Workflow
 
-Use this skill when the user wants to:
+1. **Understand the brief and scope.** Identify purpose, audience, required content and behavior, technical constraints, and any brand or accessibility requirements from the request and existing code. Clarify missing requirements when they materially affect the result. Resolve routine choices from context and state important assumptions.
+2. **Choose a coherent direction.** When the visual direction is open, explore contrasting concepts grounded in the brief, the user's taste, and concrete visual references. Vary composition and interaction, not just color. Use available feedback to refine the direction, then commit to a coherent, memorable aesthetic. For a scoped edit, preserve the existing design system, tokens, fonts, components, and interaction conventions unless the user requests a change.
 
-- Create a new web page, landing page, dashboard, or app UI
-- Design or redesign frontend components or screens
-- Improve typography, layout, color, motion, or overall visual polish
-- Convert a concept or brief into a high‑fidelity, coded interface
+   When exploring alternative designs for early user direction, generate a fresh random alphanumeric string with a shell command for each option. Use patterns in the seed to inspire typography, palette, composition, or interaction. Keep the seed out of the UI and product copy.
 
-## Inputs to Gather (or Assume)
+3. **Implement within the project.** Reuse the established stack and components. Build the requested behavior, content, and relevant loading, empty, error, and success states. Make styling easy to maintain through the project's tokens or CSS variables. Choose photography, illustration, SVG, or CSS artwork to serve the content and direction. Reuse suitable project or user-provided assets, and use image generation when appropriate tools are available and authorized. Deliver usable assets, not broken placeholders.
+4. **Critique and refine.** Inspect the rendered result, not just the code. For substantial visual work, use an independent reviewer in a fresh context when available. Provide the brief, constraints, current screenshots, and visual references—not code, prior critiques, or implementation rationale. Ask for specific, prioritized improvements to hierarchy, composition, clarity, and detail. Remove redundant copy, containers, and decoration that weaken the task or aesthetic, while preserving essential information and usable controls.
+5. **Verify and finish.** Check the working result at relevant viewport sizes and interaction states. Verify keyboard use, focus, legibility, and reduced-motion behavior. Fix problems within scope. Keep the explanation proportional to the task, covering changed files, meaningful design decisions, verification, and remaining gaps. State when visual verification was unavailable. If delivering standalone code, include complete runnable files and necessary setup. For code-only requests, omit the design narration.
 
-Before coding, identify:
+## Design standards
 
-- **Purpose & audience**: What problem does this UI solve? Who uses it?
-- **Brand/voice**: Any reference brands, tone, or visual inspiration?
-- **Technical constraints**: Framework, library, CSS strategy, accessibility, performance
-- **Content constraints**: Required copy, assets, data, features
-
-If the user did not provide this, ask **2–4 targeted questions**, or state reasonable assumptions in a short preface.
-
-## Design Thinking (Required)
-
-Commit to a **single, bold aesthetic direction**. Name it and execute it consistently. Examples:
-
-- Brutalist / raw / utilitarian
-- Editorial / magazine / typographic
-- Luxury / refined / minimal
-- Retro‑futuristic / cyber / neon
-- Art‑deco / geometric / ornamental
-- Handcrafted / organic / textured
-
-**Avoid generic AI aesthetics.** No “default” fonts, color schemes, or stock layouts.
-
-Before writing code, define the system:
-
-1. **Visual direction** — one sentence that describes the vibe
-2. **Differentiator** — what should be memorable about this UI?
-3. **Typography system** — display + body fonts, scale, weight, casing
-4. **Color system** — dominant, accent, neutral; define as CSS variables
-5. **Layout strategy** — grid rhythm, spacing scale, hierarchy plan
-6. **Motion strategy** — 1–2 meaningful interaction moments
-
-If the user wants code only, skip the explanation but still follow this internally.
-
-## Implementation Principles
-
-- **Working code**: HTML/CSS/JS or framework code that runs as‑is
-- **Semantic & accessible**: headings, labels, focus states, keyboard nav
-- **Responsive**: fluid layouts, breakpoints, responsive typography
-- **Tokenized styling**: CSS variables for colors, spacing, radii, shadows
-- **Modern layout**: prefer CSS Grid/Flex, avoid brittle positioning hacks
-
-## Aesthetic Guidelines
-
-### Typography
-
-- Typography should define the voice of the design
-- Avoid default fonts (Inter, Roboto, Arial, system stacks)
-- Use a **distinct display font** + a **refined body font**
-- Implement a clear hierarchy (size, weight, spacing, casing)
-
-### Color & Theme
-
-- Commit to a palette with a strong point‑of‑view
-- Avoid timid, overused gradients (e.g., purple‑to‑pink on white)
-- Use contrast intentionally and check legibility
-
-### Composition & Layout
-
-- Encourage asymmetry, scale contrast, overlap, or grid breaks
-- Use negative space deliberately (or controlled density if maximalist)
-- Create visual rhythm and hierarchy through spacing and alignment
-
-### Detail & Atmosphere
-
-- Add texture or depth when appropriate (noise, grain, subtle patterns)
-- Use shadows/glows only when they serve the concept
-- Consider unique borders, masks, or clip‑paths for distinct shapes
-
-### Motion & Interaction
-
-- Use motion sparingly but meaningfully
-- Favor one standout interaction over many tiny ones
-- Honor `prefers-reduced-motion`
-
-## Avoid
-
-- Cookie‑cutter hero + 3 card layouts
-- Generic gradients and default font choices
-- Unmotivated decorative elements
-- Overly flat, characterless component libraries
-
-## Deliverables
-
-- Provide full code with file names or component boundaries
-- Make customization easy with CSS variables or config objects
-- If assets are needed, provide inline SVGs or generative CSS patterns
-
-## Quality Checklist (Self‑validate)
-
-- Aesthetic direction is unmistakable
-- Typography feels intentional and expressive
-- Layout and spacing are consistent and purposeful
-- Color palette feels cohesive and legible
-- Interactions enhance the experience without clutter
-- Code runs as provided and is production‑ready
-
-**Remember:** a design is only as strong as its commitment. Choose a direction and execute it relentlessly.
+- **Intentional typography.** Establish a clear hierarchy through size, weight, spacing, and casing. For open-ended work, choose expressive type rather than defaulting to generic font choices. Pair display and body faces when useful.
+- **Cohesive color and composition.** Use a purposeful palette with readable contrast. Create rhythm with spacing, alignment, scale, and deliberate negative space or density. Asymmetry, grid breaks, texture, borders, and depth should serve the concept, not become decoration for its own sake.
+- **Distinctiveness without novelty for its own sake.** Avoid interchangeable hero-and-card compositions or fashionable gradients as an automatic answer to an open brief. A restrained layout or familiar component can be right when it serves the content and product.
+- **Semantic, accessible behavior.** Use meaningful headings and landmarks, labeled controls, visible focus, keyboard navigation, and sufficient contrast. Preserve usability across interaction states, not just in a static screenshot.
+- **Responsive implementation.** Use fluid layouts, appropriate breakpoints and typography, and robust Grid/Flex composition instead of brittle positioning. Check overflow and content variation on small and large screens.
+- **Purposeful motion.** Use restrained animation to support interactions or the visual direction. Avoid distracting loops and competing effects. Honor `prefers-reduced-motion`, and keep essential information available without animation.

package/themes/tau-dark.json

@@ -32,6 +32,10 @@
     "thinkingText": "gray",
 
     "selectedBg": "selectedBg",
+    "scrollbarTrack": "darkGray",
+    "scrollbarThumb": "",
+    "searchMatchBg": "selectedBg",
+    "searchMatchText": "",
     "userMessageBg": "userMsgBg",
     "userMessageText": "",
     "customMessageBg": "customMsgBg",

package/extensions/openai-fast.ts

@@ -1,229 +0,0 @@
-import { mkdir, readFile, writeFile } from "node:fs/promises";
-import path from "node:path";
-import {
-  getAgentDir,
-  type ExtensionAPI,
-  type ExtensionContext,
-} from "@earendil-works/pi-coding-agent";
-
-const STATUS_KEY = "openai-fast";
-const SUPPORTED_APIS = new Set([
-  "openai-responses",
-  "openai-codex-responses",
-  "azure-openai-responses",
-]);
-
-type FastMode = "fast";
-type FastSetting = FastMode | "auto";
-type JsonObject = Record<string, unknown>;
-type ModelInfo = NonNullable<ExtensionContext["model"]>;
-type FastConfig = {
-  models: Record<string, FastMode>;
-};
-
-function emptyConfig(): FastConfig {
-  return { models: {} };
-}
-
-function getConfigPath(): string {
-  return path.join(getAgentDir(), "openai-fast.json");
-}
-
-function isObject(value: unknown): value is JsonObject {
-  return typeof value === "object" && value !== null && !Array.isArray(value);
-}
-
-function normalizeFastMode(value: string): FastMode | undefined {
-  return value.trim().toLowerCase() === "fast" ? "fast" : undefined;
-}
-
-function parseFastSetting(value: string): FastSetting | undefined {
-  const normalized = value.trim().toLowerCase();
-
-  if (normalized === "on" || normalized === "enabled") return "fast";
-  if (normalized === "off" || normalized === "disabled") return "auto";
-
-  return undefined;
-}
-
-function getFastArgumentCompletions(
-  prefix: string,
-): Array<{ value: string; label: string }> | null {
-  const trimmed = prefix.trim().toLowerCase();
-  if (trimmed.includes(" ")) return null;
-
-  const options = ["on", "off", "enabled", "disabled"];
-  const matches = options.filter((option) => option.startsWith(trimmed));
-  if (!matches.length) return null;
-
-  return matches.map((option) => ({ value: option, label: option }));
-}
-
-function parseConfig(value: unknown): FastConfig {
-  if (!isObject(value) || !isObject(value.models)) return emptyConfig();
-
-  const models: Record<string, FastMode> = {};
-  for (const [key, rawMode] of Object.entries(value.models)) {
-    const normalizedKey = key.trim();
-    if (!normalizedKey || typeof rawMode !== "string") continue;
-
-    const mode = normalizeFastMode(rawMode);
-    if (!mode) continue;
-
-    models[normalizedKey] = mode;
-  }
-
-  return { models };
-}
-
-async function loadConfig(): Promise<FastConfig> {
-  try {
-    const raw = await readFile(getConfigPath(), "utf8");
-    return parseConfig(JSON.parse(raw) as unknown);
-  } catch (error) {
-    const code = (error as NodeJS.ErrnoException).code;
-    if (code !== "ENOENT") {
-      const message = error instanceof Error ? error.message : String(error);
-      console.warn(`[openai-fast] Failed to load config: ${message}`);
-    }
-
-    return emptyConfig();
-  }
-}
-
-async function saveConfig(config: FastConfig): Promise<void> {
-  const configPath = getConfigPath();
-  await mkdir(path.dirname(configPath), { recursive: true });
-  await writeFile(configPath, `${JSON.stringify(config, null, 2)}\n`, "utf8");
-}
-
-function isSupportedModel(model: ExtensionContext["model"]): model is ModelInfo {
-  return !!model && SUPPORTED_APIS.has(model.api);
-}
-
-function getExactModelKey(model: Pick<ModelInfo, "provider" | "id">): string {
-  return `${model.provider}/${model.id}`;
-}
-
-function resolveFastMode(
-  config: FastConfig,
-  model: Pick<ModelInfo, "provider" | "id">,
-): { key?: string; mode?: FastMode } {
-  const exactKey = getExactModelKey(model);
-  const exactMode = config.models[exactKey];
-  if (exactMode) return { key: exactKey, mode: exactMode };
-
-  const sharedMode = config.models[model.id];
-  if (sharedMode) return { key: model.id, mode: sharedMode };
-
-  return {};
-}
-
-function setFastMode(config: FastConfig, key: string, setting: FastSetting): FastConfig {
-  const models = { ...config.models };
-
-  if (setting === "auto") delete models[key];
-  else models[key] = setting;
-
-  return { models };
-}
-
-function updateStatus(ctx: ExtensionContext, config: FastConfig): void {
-  if (!ctx.hasUI) return;
-  if (!isSupportedModel(ctx.model)) {
-    ctx.ui.setStatus(STATUS_KEY, undefined);
-    return;
-  }
-
-  const { mode } = resolveFastMode(config, ctx.model);
-  ctx.ui.setStatus(STATUS_KEY, mode ? ctx.ui.theme.fg("dim", mode) : undefined);
-}
-
-export default function openaiFastExtension(pi: ExtensionAPI): void {
-  let config = emptyConfig();
-
-  async function applySetting(setting: FastSetting, ctx: ExtensionContext): Promise<void> {
-    const model = ctx.model;
-    if (!model) {
-      ctx.ui.notify("No active model.", "warning");
-      return;
-    }
-
-    if (!isSupportedModel(model)) {
-      ctx.ui.notify(
-        "Current model does not support fast mode. Supported APIs: openai-responses, openai-codex-responses, azure-openai-responses.",
-        "warning",
-      );
-      updateStatus(ctx, config);
-      return;
-    }
-
-    const resolved = resolveFastMode(config, model);
-    const configKey = resolved.key ?? getExactModelKey(model);
-    const nextConfig = setFastMode(config, configKey, setting);
-
-    try {
-      await saveConfig(nextConfig);
-    } catch (error) {
-      const message = error instanceof Error ? error.message : String(error);
-      ctx.ui.notify(`Failed to save ${getConfigPath()}: ${message}`, "error");
-      return;
-    }
-
-    config = nextConfig;
-    updateStatus(ctx, config);
-
-    const modelLabel = getExactModelKey(model);
-    if (setting === "auto") {
-      ctx.ui.notify(`Fast mode reset to auto for ${modelLabel}`, "info");
-      return;
-    }
-
-    ctx.ui.notify(`Fast mode enabled for ${modelLabel}`, "info");
-  }
-
-  pi.registerCommand("fast", {
-    description: "Toggle priority service tier for the current OpenAI model",
-    getArgumentCompletions: getFastArgumentCompletions,
-    handler: async (args, ctx) => {
-      const arg = args.trim();
-      if (arg === "") {
-        const nextSetting: FastSetting =
-          isSupportedModel(ctx.model) && resolveFastMode(config, ctx.model).mode ? "auto" : "fast";
-        await applySetting(nextSetting, ctx);
-        return;
-      }
-
-      const setting = parseFastSetting(arg);
-      if (!setting) {
-        ctx.ui.notify("Usage: /fast [on|off|enabled|disabled]", "error");
-        return;
-      }
-
-      await applySetting(setting, ctx);
-    },
-  });
-
-  pi.on("session_start", async (_event, ctx) => {
-    config = await loadConfig();
-    updateStatus(ctx, config);
-  });
-
-  pi.on("model_select", async (_event, ctx) => {
-    updateStatus(ctx, config);
-  });
-
-  pi.on("before_provider_request", (event, ctx) => {
-    const model = ctx.model;
-    if (!isSupportedModel(model)) return;
-    if (!resolveFastMode(config, model).mode) return;
-
-    const payload = event.payload;
-    if (!isObject(payload)) return;
-
-    return {
-      ...payload,
-      service_tier: "priority",
-    };
-  });
-}

package/extensions/websearch/providers/openai-codex.browser.ts

@@ -1,77 +0,0 @@
-import type { BrowserSession, WebsearchResult } from "../types.js";
-import { browserHeaders, buildCookieHeader } from "../normalize.js";
-import { fetchJson, withTimeout } from "./shared.js";
-import { decodeJwtAccountId, runOpenAICodexSearch } from "./openai-codex.shared.js";
-
-const CHATGPT_BASE_URL = "https://chatgpt.com";
-const SESSION_URL = `${CHATGPT_BASE_URL}/api/auth/session`;
-const PREFERRED_MODELS = ["gpt-5.4", "gpt-5.3-codex-spark", "gpt-5.1-codex-mini"];
-
-interface ChatGptSessionPayload {
-  accessToken?: string;
-  user?: {
-    email?: string;
-    name?: string;
-  };
-}
-
-export const browserOpenAICodex = {
-  backend: "openai-codex" as const,
-  domains: ["chatgpt.com"],
-  async search(
-    session: BrowserSession,
-    query: string,
-    signal?: AbortSignal,
-  ): Promise<WebsearchResult> {
-    const cookieHeader = buildCookieHeader(SESSION_URL, session.cookies);
-    if (!cookieHeader) {
-      throw new Error("No ChatGPT session cookies found in browser profile.");
-    }
-
-    const chatSession = await fetchJson<ChatGptSessionPayload>(SESSION_URL, {
-      headers: browserHeaders({
-        cookieHeader,
-        origin: CHATGPT_BASE_URL,
-        referer: `${CHATGPT_BASE_URL}/`,
-      }),
-      signal: withTimeout(signal, 20_000),
-    });
-
-    if (!chatSession.accessToken) {
-      throw new Error("No ChatGPT access token found in session.");
-    }
-
-    const result = await searchWithPreferredModel(chatSession.accessToken, query, signal);
-
-    return {
-      backend: "openai-codex",
-      authSource: session.profile.family,
-      browserName: session.profile.browserName,
-      profile: session.profile.profileName,
-      accountLabel: chatSession.user?.email ?? chatSession.user?.name,
-      answer: result.answer,
-      sources: result.sources,
-    };
-  },
-};
-
-async function searchWithPreferredModel(accessToken: string, query: string, signal?: AbortSignal) {
-  let lastError: string | null = null;
-
-  for (const model of PREFERRED_MODELS) {
-    try {
-      return await runOpenAICodexSearch({
-        apiKey: accessToken,
-        accountId: decodeJwtAccountId(accessToken),
-        model,
-        query,
-        baseUrl: `${CHATGPT_BASE_URL}/backend-api`,
-        signal,
-      });
-    } catch (error) {
-      lastError = error instanceof Error ? error.message : String(error);
-    }
-  }
-
-  throw new Error(lastError ?? "ChatGPT Codex search failed.");
-}