fix: make well-known discovery compatible with npx skills CLI by johnmcollier · Pull Request #49 · redhat-ai-dev/rhess

johnmcollier · 2026-07-16T14:12:23Z

Summary

Fix /.well-known/agent-skills/index.json $schema to the exact URI required by npx skills (https://schemas.agentskills.io/discovery/0.2.0/schema.json), which was rejecting RHESS indexes as empty.
Emit kebab-case slugs as discovery names, truncate descriptions to 1024 chars, and change installCommand to npx skills add <host> --skill <slug>.
Document PUBLIC_BASE_URL for TLS-terminating proxies so artifact/install URLs use https://.

Test plan

npx vitest run test/server/routes/wellKnown.test.ts test/server/routes/skills.test.ts
Local RHESS + npx skills add <host> --skill appinsights-instrumentation --list succeeds after schema fix
After deploy: npx skills add https://<route> --skill appinsights-instrumentation
Confirm required CI (Build/Lint/Test + image + prow images) green; OpenShift e2e is optional

Made with Cursor

Emit the exact Agent Skills discovery $schema URI the CLI matches on, use kebab-case slugs as install names, and generate installCommand as host + --skill so adds no longer fail with "No skills found". Assisted-by: Cursor Grok 4.5 Co-authored-by: Cursor <cursoragent@cursor.com>

openshift-ci · 2026-07-16T14:12:29Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: johnmcollier

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

qodo-code-review · 2026-07-16T14:13:49Z

PR Summary by Qodo

Fix well-known discovery and installCommand for npx skills CLI

🐞 Bug fix 🧪 Tests 📝 Documentation ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Emit the exact Agent Skills discovery $schema URI required by npx skills.
• Make discovery entries CLI-safe (kebab-case name, 1024-char description limit).
• Generate installCommand as npx skills add  --skill  and document PUBLIC_BASE_URL.

Diagram

graph TD
  CLI{{"npx skills CLI"}} --> SVC["RHESS server"] --> WK["/.well-known index"] --> ART["Artifact URL"]
  SVC --> SK["Skills API"] --> CMD["installCommand"] --> CLI
  ENV["PUBLIC_BASE_URL env"] --> SVC

High-Level Assessment

The following are alternative approaches to this PR:

1. Enable Fastify trustProxy + derive URL from X-Forwarded-*

➕ Avoids needing PUBLIC_BASE_URL in proxy deployments
➕ Automatically reflects external scheme/host for multi-route deployments
➖ Requires correct trustProxy configuration; unsafe if misconfigured
➖ Adds operational complexity; forwarded headers are otherwise client-controlled

2. Expose a dedicated CLI install endpoint (non-standard)

➕ Could accept direct artifact URLs and avoid discovery semantics mismatch
➖ Diverges from Agent Skills spec and CLI expectations
➖ Adds a parallel surface area to maintain and document

Recommendation: Keep the PR’s approach: matching the CLI’s exact $schema URI and emitting CLI-compatible discovery fields is the most reliable way to restore npx skills interoperability. PUBLIC_BASE_URL is a pragmatic and secure default for proxy/TLS-termination scenarios; if deployments commonly run behind ingress, consider optionally supporting trustProxy in the future, but only with explicit configuration and clear security guidance.

Files changed (7) +97 / -10

Bug fix (2) +18 / -5

skills.tsGenerate installCommand targeting host + --skill and tighten schema docs +8/-2

Generate installCommand targeting host + --skill and tighten schema docs

• Changes installCommand generation to point at the server base URL with a '--skill <slug>' filter so the CLI installs via well-known discovery rather than a direct artifact URL. Updates the OpenAPI/JSON schema description for installCommand and adds PUBLIC_BASE_URL-aware base URL resolution.

src/server/routes/skills.ts

wellKnown.tsMake discovery index match npx skills expectations ($schema, name, description) +10/-3

Make discovery index match npx skills expectations ($schema, name, description)

• Emits the exact opaque $schema URI required by the Agent Skills discovery spec/CLI. Uses the kebab-case slug as the discovery 'name' and truncates descriptions to 1024 characters with an ellipsis to avoid CLI rejection, while continuing to provide artifact URLs and digests.

src/server/routes/wellKnown.ts

Tests (2) +67 / -1

skills.test.tsAdd assertion for host-based installCommand format +13/-0

Add assertion for host-based installCommand format
• Adds a test ensuring the skills listing returns installCommand as 'npx skills add http://<host> --skill <slug>'. Verifies behavior using an injected Host header.
test/server/routes/skills.test.ts

wellKnown.test.tsStrengthen discovery index tests for schema URI, slug name, and truncation +54/-1

Strengthen discovery index tests for schema URI, slug name, and truncation
• Updates the $schema assertion to require the exact CLI-matched URI. Adds tests verifying discovery 'name' is a kebab-case slug and that descriptions longer than 1024 characters are truncated with an ellipsis.
test/server/routes/wellKnown.test.ts

Documentation (1) +4 / -4

api.mdUpdate discovery schema URI and installCommand documentation/examples +4/-4

Update discovery schema URI and installCommand documentation/examples

• Updates JSON examples to use the exact discovery schema URI expected by the Agent Skills CLI. Rewrites install guidance to use 'npx skills add <host> --skill <slug>' and clarifies that installCommand should not use the artifact URL directly.

docs/api.md

Other (2) +8 / -0

.env.exampleDocument PUBLIC_BASE_URL for correct external https origin +4/-0

Document PUBLIC_BASE_URL for correct external https origin

• Adds commented guidance for setting PUBLIC_BASE_URL to the external origin (no trailing slash). This ensures generated discovery artifact URLs and installCommand use https when TLS terminates upstream.

.env.example

deployment.yamlAdd deployment notes for PUBLIC_BASE_URL behind TLS-terminating ingress +4/-0

Add deployment notes for PUBLIC_BASE_URL behind TLS-terminating ingress
• Annotates the Kubernetes Deployment manifest with an example PUBLIC_BASE_URL env var. Clarifies it should point at the external https route when TLS is terminated at the ingress.
deploy/deployment.yaml

qodo-code-review · 2026-07-16T14:19:15Z

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Over-strict Host validation~~ ✓ Resolved 🐞 Bug ≡ Correctness ⭐ New

Description

isSafeHostHeader() requires the raw Host header string to exactly equal the URL-parsed authority
(parsed.host), which can reject otherwise-valid Host values that normalize during parsing (notably
hostname casing). When this happens, resolveBaseUrl() falls back to localhost, producing
incorrect public URLs/install commands in direct (non-PUBLIC_BASE_URL) deployments.

Code

src/server/utils/resolveBaseUrl.ts[R29-31]

+    // Ensure round-trip preserves the Host form we will embed (incl. [ipv6]:port).
+    const authority = parsed.host; // hostname[:port], brackets for IPv6
+    return authority === host;

Evidence

The strict round-trip equality check makes validation dependent on the URL parser preserving the
exact original string, and the new tests show that validation failures cause resolveBaseUrl() to
return http://localhost (the fallback behavior that would be triggered by such false negatives).

src/server/utils/resolveBaseUrl.ts[29-31]
test/server/utils/resolveBaseUrl.test.ts[64-67]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`isSafeHostHeader()` compares the raw Host header to `new URL(...).host` using strict equality. Because URL parsing can canonicalize the host representation, this strict check can reject valid hosts and force downstream code (via `resolveBaseUrl`) into the `localhost` fallback.

### Issue Context
The function is trying to prevent reflecting attacker-controlled origins into generated URLs, which is good. The fix should keep the security posture (reject spoof markers / userinfo / paths / query / fragments), while avoiding false negatives from harmless canonicalization.

### Fix Focus Areas
- src/server/utils/resolveBaseUrl.ts[29-31]
- test/server/utils/resolveBaseUrl.test.ts[5-35]

### Suggested fix approach
- Keep the existing structural checks (no userinfo, pathname == "/", no search/hash, valid port range).
- Replace `authority === host` with a safer normalization-aware comparison, e.g. comparing case-insensitively (`authority.toLowerCase() === host.toLowerCase()`), and/or emitting/using the canonical `authority` instead of the raw input.
- Add a regression test that a mixed/upper-case DNS host (e.g. `"EXAMPLE.COM"` and/or `"Example.COM:3000"`) is accepted.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~IPv6 Host breaks baseUrl~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

isSafeHostHeader() rejects valid bracketed IPv6 Host headers (e.g. [::1]:3000), so
resolveBaseUrl() falls back to http://localhost and generates incorrect artifact URLs/install
commands when RHESS is accessed via IPv6 literals without PUBLIC_BASE_URL set.

Code

src/server/utils/resolveBaseUrl.ts[R8-9]

+const SAFE_HOST_RE =
+  /^(?:(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)(?:\.(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?))*|localhost|\d{1,3}(?:\.\d{1,3}){3})(?::\d{1,5})?$/;

Evidence

The current safe-host regex only matches DNS/localhost/IPv4 with an optional port and
resolveBaseUrl() falls back to localhost when validation fails, so valid IPv6 Host syntax will
produce the fallback URL.

src/server/utils/resolveBaseUrl.ts[8-16]
src/server/utils/resolveBaseUrl.ts[27-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolveBaseUrl()` validates `req.headers.host` via a regex that only allows DNS/localhost/IPv4. Legitimate IPv6 literal hosts in the required bracket form (e.g. `[::1]:3000`) are rejected and cause a fallback to `localhost`, producing wrong public URLs.

### Issue Context
HTTP Host headers represent IPv6 literals as bracketed values; direct deployments (or local dev) can legitimately use this form. `PUBLIC_BASE_URL` is a workaround but shouldn’t be required for correct direct IPv6 access.

### Fix Focus Areas
- src/server/utils/resolveBaseUrl.ts[8-35]

### Suggested fix
- Extend host validation to accept bracketed IPv6 literals with an optional validated port (1–65535).
- Prefer a standards-based parse approach instead of growing the regex, e.g. parse `candidate` as an authority component and reject username/password/path/query/fragment.
- Add unit tests for `isSafeHostHeader()` / `resolveBaseUrl()` covering `[::1]`, `[::1]:3000`, and invalid bracket forms.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Host-derived install command spoof 🐞 Bug ⛨ Security

Description

When PUBLIC_BASE_URL is unset, the install command is built from req.protocol and the request Host
header, and is returned to users verbatim. This allows untrusted Host/protocol values (or
proxy/cache misconfiguration) to cause the UI/API to present install commands and artifact URLs
pointing at an attacker-chosen origin.

Code

src/server/routes/skills.ts[R64-67]

+  // Point at the host so the CLI discovers via /.well-known/agent-skills/index.json,
+  // then select this skill. Artifact URLs are not a valid skills-add source by themselves
+  // and would make the CLI fetch every skill in the index.
+  const installCommand = `npx skills add ${baseUrl} --skill ${skill.slug}`;

Evidence

The new installCommand includes baseUrl and baseUrl is derived from
req.headers.host/req.protocol when PUBLIC_BASE_URL is not set, so the returned command/URLs can
reflect request-controlled origin data.

src/server/routes/skills.ts[55-68]
src/server/routes/wellKnown.ts[19-30]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`installCommand` now embeds `baseUrl`, and `baseUrl` falls back to `${req.protocol}://${req.headers.host}` when `PUBLIC_BASE_URL` is unset. Because Host/protocol are request-derived, the API/UI can emit spoofed origins in install commands/discovery URLs.

## Issue Context
This is not automatic code execution; the primary risk is command/URL spoofing (phishing) and, in some deployments, cache poisoning if responses are cached without varying by Host.

## Fix Focus Areas
- src/server/routes/skills.ts[55-68]
- src/server/routes/wellKnown.ts[19-30]

## Suggested fix
1. Prefer making `PUBLIC_BASE_URL` mandatory for production deployments (fail fast at startup unless `NODE_ENV=development` or similar).
2. If keeping a fallback, strictly validate/sanitize the fallback host and protocol:
  - Allow only `http`/`https`.
  - Validate host against a safe hostname/host:port regex and reject suspicious values.
  - Consider deriving the port from server config rather than reflecting arbitrary Host header values.
3. Add a test ensuring invalid Host values do not get reflected into `installCommand` / discovery URLs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

View more (1)

4. ~~Unvalidated slug breaks CLI~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

Discovery now emits name: s.slug and the API install command uses --skill ${skill.slug}, but
slugs are ingested directly from directory basenames without validation/normalization. Any skill
directory not matching the required kebab-case install id format can produce an invalid discovery
index and a non-working copy/paste install command.

Code

src/server/routes/wellKnown.ts[R73-80]

+        // Discovery `name` must be a kebab-case install id ([a-z0-9-]+). Prefer slug
+        // over frontmatter display names that may contain spaces or mixed case.
+        name: s.slug,
        type: s.artifactType,
-        description: s.description,
+        // CLI rejects descriptions longer than 1024 characters.
+        description: s.description.length > 1024
+          ? `${s.description.slice(0, 1023)}…`
+          : s.description,

Evidence
wellKnown discovery now uses slug as the discovery name, and the skills API uses slug directly
in the generated CLI command; however, ingestion derives slug directly from directory names with
path.basename() and does not validate it against the kebab-case constraint documented/tested for
CLI compatibility.
src/server/routes/wellKnown.ts[66-83]
src/server/routes/skills.ts[55-84]
src/server/ingestion/discover.ts[64-70]
src/server/ingestion/discover.ts[100-107]
src/server/ingestion/ingest.ts[44-79]
test/server/routes/wellKnown.test.ts[108-117]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The discovery index and installCommand now depend on `slug` being a CLI-compatible kebab-case identifier, but ingestion derives `slug` from directory names with no validation. This can yield invalid discovery `name` values and install commands that fail to parse/work.

## Issue Context
- Discovery output uses `name: s.slug`.
- `installCommand` uses `--skill ${skill.slug}`.
- Slugs originate from `path.basename(...)` of directories.

## Fix Focus Areas
- src/server/routes/wellKnown.ts[66-83]
- src/server/routes/skills.ts[55-84]
- src/server/ingestion/discover.ts[49-111]
- src/server/ingestion/ingest.ts[38-96]

## Suggested fix
1. Introduce a single "discovery/install id" validation rule (e.g. `/^[a-z0-9]+(?:-[a-z0-9]+)*$/`).
2. Enforce it during ingestion (preferred):
  - If the derived slug is invalid, either:
    - **Reject** the candidate (add to `failures` with a clear reason), or
    - **Normalize** (slugify) and handle collisions deterministically (e.g., append `-2`, `-3`, etc.) while recording the original for display.
3. Make `installCommand` more robust against parsing edge-cases by using `--skill=${skill.slug}` (single token) and/or quoting/escaping the value.
4. Add tests covering invalid directory names (spaces/underscores/uppercase and leading `-`) to ensure ingestion + discovery remain CLI-compatible.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 5de6fad

Results up to commit 40e6924

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Host-derived install command spoof 🐞 Bug ⛨ Security

Description

When PUBLIC_BASE_URL is unset, the install command is built from req.protocol and the request Host
header, and is returned to users verbatim. This allows untrusted Host/protocol values (or
proxy/cache misconfiguration) to cause the UI/API to present install commands and artifact URLs
pointing at an attacker-chosen origin.

Code

src/server/routes/skills.ts[R64-67]

+  // Point at the host so the CLI discovers via /.well-known/agent-skills/index.json,
+  // then select this skill. Artifact URLs are not a valid skills-add source by themselves
+  // and would make the CLI fetch every skill in the index.
+  const installCommand = `npx skills add ${baseUrl} --skill ${skill.slug}`;

Evidence

The new installCommand includes baseUrl and baseUrl is derived from
req.headers.host/req.protocol when PUBLIC_BASE_URL is not set, so the returned command/URLs can
reflect request-controlled origin data.

src/server/routes/skills.ts[55-68]
src/server/routes/wellKnown.ts[19-30]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`installCommand` now embeds `baseUrl`, and `baseUrl` falls back to `${req.protocol}://${req.headers.host}` when `PUBLIC_BASE_URL` is unset. Because Host/protocol are request-derived, the API/UI can emit spoofed origins in install commands/discovery URLs.

## Issue Context
This is not automatic code execution; the primary risk is command/URL spoofing (phishing) and, in some deployments, cache poisoning if responses are cached without varying by Host.

## Fix Focus Areas
- src/server/routes/skills.ts[55-68]
- src/server/routes/wellKnown.ts[19-30]

## Suggested fix
1. Prefer making `PUBLIC_BASE_URL` mandatory for production deployments (fail fast at startup unless `NODE_ENV=development` or similar).
2. If keeping a fallback, strictly validate/sanitize the fallback host and protocol:
  - Allow only `http`/`https`.
  - Validate host against a safe hostname/host:port regex and reject suspicious values.
  - Consider deriving the port from server config rather than reflecting arbitrary Host header values.
3. Add a test ensuring invalid Host values do not get reflected into `installCommand` / discovery URLs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Unvalidated slug breaks CLI~~ ✓ Resolved 🐞 Bug ≡ Correctness

Description

Discovery now emits name: s.slug and the API install command uses --skill ${skill.slug}, but
slugs are ingested directly from directory basenames without validation/normalization. Any skill
directory not matching the required kebab-case install id format can produce an invalid discovery
index and a non-working copy/paste install command.

Code

src/server/routes/wellKnown.ts[R73-80]

+        // Discovery `name` must be a kebab-case install id ([a-z0-9-]+). Prefer slug
+        // over frontmatter display names that may contain spaces or mixed case.
+        name: s.slug,
        type: s.artifactType,
-        description: s.description,
+        // CLI rejects descriptions longer than 1024 characters.
+        description: s.description.length > 1024
+          ? `${s.description.slice(0, 1023)}…`
+          : s.description,

Evidence
wellKnown discovery now uses slug as the discovery name, and the skills API uses slug directly
in the generated CLI command; however, ingestion derives slug directly from directory names with
path.basename() and does not validate it against the kebab-case constraint documented/tested for
CLI compatibility.
src/server/routes/wellKnown.ts[66-83]
src/server/routes/skills.ts[55-84]
src/server/ingestion/discover.ts[64-70]
src/server/ingestion/discover.ts[100-107]
src/server/ingestion/ingest.ts[44-79]
test/server/routes/wellKnown.test.ts[108-117]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The discovery index and installCommand now depend on `slug` being a CLI-compatible kebab-case identifier, but ingestion derives `slug` from directory names with no validation. This can yield invalid discovery `name` values and install commands that fail to parse/work.

## Issue Context
- Discovery output uses `name: s.slug`.
- `installCommand` uses `--skill ${skill.slug}`.
- Slugs originate from `path.basename(...)` of directories.

## Fix Focus Areas
- src/server/routes/wellKnown.ts[66-83]
- src/server/routes/skills.ts[55-84]
- src/server/ingestion/discover.ts[49-111]
- src/server/ingestion/ingest.ts[38-96]

## Suggested fix
1. Introduce a single "discovery/install id" validation rule (e.g. `/^[a-z0-9]+(?:-[a-z0-9]+)*$/`).
2. Enforce it during ingestion (preferred):
  - If the derived slug is invalid, either:
    - **Reject** the candidate (add to `failures` with a clear reason), or
    - **Normalize** (slugify) and handle collisions deterministically (e.g., append `-2`, `-3`, etc.) while recording the original for display.
3. Make `installCommand` more robust against parsing edge-cases by using `--skill=${skill.slug}` (single token) and/or quoting/escaping the value.
4. Add tests covering invalid directory names (spaces/underscores/uppercase and leading `-`) to ensure ingestion + discovery remain CLI-compatible.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Results up to commit 9b2d807

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~IPv6 Host breaks baseUrl~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

isSafeHostHeader() rejects valid bracketed IPv6 Host headers (e.g. [::1]:3000), so
resolveBaseUrl() falls back to http://localhost and generates incorrect artifact URLs/install
commands when RHESS is accessed via IPv6 literals without PUBLIC_BASE_URL set.

Code

src/server/utils/resolveBaseUrl.ts[R8-9]

+const SAFE_HOST_RE =
+  /^(?:(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)(?:\.(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?))*|localhost|\d{1,3}(?:\.\d{1,3}){3})(?::\d{1,5})?$/;

Evidence

The current safe-host regex only matches DNS/localhost/IPv4 with an optional port and
resolveBaseUrl() falls back to localhost when validation fails, so valid IPv6 Host syntax will
produce the fallback URL.

src/server/utils/resolveBaseUrl.ts[8-16]
src/server/utils/resolveBaseUrl.ts[27-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`resolveBaseUrl()` validates `req.headers.host` via a regex that only allows DNS/localhost/IPv4. Legitimate IPv6 literal hosts in the required bracket form (e.g. `[::1]:3000`) are rejected and cause a fallback to `localhost`, producing wrong public URLs.

### Issue Context
HTTP Host headers represent IPv6 literals as bracketed values; direct deployments (or local dev) can legitimately use this form. `PUBLIC_BASE_URL` is a workaround but shouldn’t be required for correct direct IPv6 access.

### Fix Focus Areas
- src/server/utils/resolveBaseUrl.ts[8-35]

### Suggested fix
- Extend host validation to accept bracketed IPv6 literals with an optional validated port (1–65535).
- Prefer a standards-based parse approach instead of growing the regex, e.g. parse `candidate` as an authority component and reject username/password/path/query/fragment.
- Add unit tests for `isSafeHostHeader()` / `resolveBaseUrl()` covering `[::1]`, `[::1]:3000`, and invalid bracket forms.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Reject non-kebab-case skill directory names at ingest, omit invalid slugs from the well-known index, quote --skill as a single token, and sanitize Host headers so spoofed origins are not reflected into installCommand / artifact URLs. Assisted-by: Cursor Grok 4.5 Co-authored-by: Cursor <cursoragent@cursor.com>

johnmcollier · 2026-07-16T14:20:49Z

/agentic_review

qodo-code-review · 2026-07-16T14:27:41Z

Code review by qodo was updated up to the latest commit 9b2d807

Parse Host as a URL authority so legitimate [::1]:port values are kept while credentials/path/query spoof forms still fall back to localhost. Assisted-by: Cursor Grok 4.5 Co-authored-by: Cursor <cursoragent@cursor.com>

johnmcollier · 2026-07-16T14:29:45Z

/agentic_review

qodo-code-review · 2026-07-16T14:35:03Z

Code review by qodo was updated up to the latest commit cc9299d

Compare Host to the URL parser authority case-insensitively and emit the canonical host form so mixed-case DNS/IPv6 values no longer fall back to localhost. Assisted-by: Cursor Grok 4.5 Co-authored-by: Cursor <cursoragent@cursor.com>

qodo-code-review Bot reviewed Jul 16, 2026

View reviewed changes

Comment thread src/server/routes/wellKnown.ts Outdated

Comment thread src/server/routes/skills.ts Outdated

qodo-code-review Bot reviewed Jul 16, 2026

View reviewed changes

Comment thread src/server/utils/resolveBaseUrl.ts Outdated

fix: accept bracketed IPv6 Host headers in resolveBaseUrl

cc9299d

Parse Host as a URL authority so legitimate [::1]:port values are kept while credentials/path/query spoof forms still fall back to localhost. Assisted-by: Cursor Grok 4.5 Co-authored-by: Cursor <cursoragent@cursor.com>

qodo-code-review Bot reviewed Jul 16, 2026

View reviewed changes

Comment thread src/server/utils/resolveBaseUrl.ts Outdated

johnmcollier merged commit b8d4b5f into redhat-ai-dev:main Jul 16, 2026
2 of 4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: make well-known discovery compatible with npx skills CLI#49

fix: make well-known discovery compatible with npx skills CLI#49
johnmcollier merged 4 commits into
redhat-ai-dev:mainfrom
johnmcollier:fix/well-known-discovery-schema

johnmcollier commented Jul 16, 2026

Uh oh!

openshift-ci Bot commented Jul 16, 2026

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

Uh oh!

qodo-code-review Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

johnmcollier commented Jul 16, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

Uh oh!

johnmcollier commented Jul 16, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

johnmcollier commented Jul 16, 2026

Summary

Test plan

Uh oh!

openshift-ci Bot commented Jul 16, 2026

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

PR Summary by Qodo

Uh oh!

qodo-code-review Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

Uh oh!

Uh oh!

johnmcollier commented Jul 16, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

Uh oh!

johnmcollier commented Jul 16, 2026

Uh oh!

Uh oh!

qodo-code-review Bot commented Jul 16, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-code-review Bot commented Jul 16, 2026 •

edited

Loading