diegosouzapw/OmniRoute

Problem / context The Pi entry is present in the CLI Code catalog, but it has no guide steps or dedicated card, so its detail page falls back to “Coming soon.” The current catalog entry is configType: "custom" (src/shared/constants/cliTools.ts). This leaves a misleading dead end for users who reasonably expect to configure OmniRoute from the dashboard. There is already a Pi settings implementation in this repository/upstream (/api/cli-tools/pi-settings, introduced with the Pi CLI tools work in PR #6318), but it appears to target Pi's legacy ~/.pi/config.json shape (baseUrl, apiKey, model). Current Pi supports custom providers/models through ~/.pi/agent/models.json; config should use the documented provider object (baseUrl, api, apiKey, models[]). Please verify the Pi version/config contract against current upstream docs during implementation rather than extending the legacy config blindly. Prior art and fork status Upstream OmniRoute main already has /api/cli-tools/pi-settings and

Summary In investigating chatgpt-web failures on OmniRoute v3.8.51 (live on a Linux deployment), we identified two concrete failure points preventing the provider from working on current chatgpt.com: First-party asset discovery failure: ChatGPT changed its frontend script paths from /cdn/assets/ to /unauth-mweb/assets/, causing discoverFirstPartyModule() to reject all scripts and abort with [400]: Error: ChatGPT Web first-party request module was not loaded. __Host- cookie RFC 6265bis validation error: Exported session cookies with domain: ".chatgpt.com" cause Playwright to reject the storage state with Protocol error (Storage.setCookies): Invalid cookie fields -> browser.newContext: Error setting storage state:. 1. Asset Discovery Failure (ChatGPT Web first-party request module was not loaded) What happens Requests to chatgpt-web/* models stall and abort with: [400]: Error: ChatGPT Web first-party request module was not loaded or hang until upstream timeout (504). Root Cause In op

Summary When PII_RESPONSE_SANITIZATION is enabled, the ipv6_address pattern in src/lib/piiSanitizer.ts rewrites any :: in a model response to [IP_REDACTED]. A double colon is load-bearing syntax in at least seven languages, so this corrupts code responses: Language Input Corrupted to Python s[::-1] s[[IP_REDACTED]-1] Haskell / Scala x :: Int x [IP_REDACTED] Int Elixir @spec f(a :: integer) @spec f(a [IP_REDACTED] integer) Markdown :::note [IP_REDACTED]note Why this is worse than a cosmetic glitch The corrupted output is usually still syntactically valid. def f(s): return s[[IP_REDACTED]-1] is a legal function definition — and a file that defines a function but never calls it runs clean. Any downstream execution gate therefore reports exit 0 on code that cannot work. That is how I hit it: a code-generation pipeline ran the returned file, saw exit code 0, and reported the task as passing. The code had been silently rewritten before it was ever written to disk. Root caus

Description npm run check:cycles reports 14 strongly connected components across 5057 files: - SCC (43 files): src/lib/db/ (apiKeyGroups, apiKeys, combos, core, models, providers, proxies, quotaPools, settings, etc.) - SCC (5 files): open-sse/handlers/imageGeneration/ + providers - SCC (5 files): open-sse/services/adobeFirefly* - SCC (3 files): open-sse/mcp-server/catalog.ts, radarCatalog.ts, server.ts - ... 10 more SCCs (2-4 files each) Impact Circular dependencies: Increase build time and memory usage Make testing harder (can't isolate modules) Risk runtime initialization order bugs Violate architectural layering Location Primary: src/lib/db/ — 43 files in a single SCC Expected Refactor to break cycles, e.g.: Extract shared types to src/lib/db/types/ or src/shared/types/ Use lazy imports (await import(...)) for optional dependencies Introduce interface barriers between domain modules Note This is currently advisory (not blocking) per AGENTS.md, but the largest SCC in the DB la

Description The isLocalOnlyPath() function in src/server/authz/routeGuard.ts classifies routes as LOCAL_ONLY (loopback-enforced) to prevent RCE-via-tunnel attacks on spawn-capable endpoints. However, there are no tests verifying it correctly handles: URL-encoded paths (e.g., /api/mcp/%2e%2e/ or /api/mcp/..%2f) Double slashes (/api//mcp/) Case variations (/API/MCP/) Path traversal (/api/mcp/../mcp/) Mixed encodings Location src/server/authz/routeGuard.ts:343-354 (isLocalOnlyPath function) Risk If a reverse proxy or load balancer normalizes paths differently than Next.js, an attacker could bypass the LOCAL_ONLY guard and trigger child-process spawns via leaked JWT through a tunnel (CVE class GHSA-fhh6-4qxv-rpqj). Expected Add test cases to tests/unit/check-route-guard-membership.test.ts covering all normalization edge cases, asserting isLocalOnlyPath() returns true for all variants of LOCAL_ONLY prefixes. Related Hard Rules #15, #17 (spawn-capable routes must be loopback-enforced) GHS