fix(cli): validate external download inputs

[marius-kilocode]

GitHub Action comments currently allow attachment-like URLs to flow directly into authenticated requests, while language server release metadata influences archive and executable paths. This exposes request-forgery and command-injection trust boundaries reported by code scanning.

Canonicalize GitHub attachment URLs to the two supported route shapes before fetching them. Language server downloads now use fixed local archive names, clangd release tags are allowlisted before becoming executable paths, and Windows ZIP extraction passes paths through environment variables instead of embedding them in PowerShell source.

The attachment policy and regression coverage live in Kilo-owned paths. Shared OpenCode files retain only narrow, annotated validation hooks to limit future upstream merge conflicts.

Addresses:

• https://github.com/Kilo-Org/kilocode/security/code-scanning/3
• https://github.com/Kilo-Org/kilocode/security/code-scanning/4
• https://github.com/Kilo-Org/kilocode/security/code-scanning/5

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	0
SUGGESTION	1

Issue Details (click to expand)

SUGGESTION

File	Line	Issue
packages/opencode/src/kilocode/security/github.ts	10	encodeURIComponent on a validated UUID is a no-op — UUID characters ([0-9a-fA-F-]) are all URL-safe. Consider using the captured group directly for clarity.

Other Observations (not in diff)

• packages/opencode/src/lsp/server.ts line 1469: release.tag_name is used unvalidated to construct assetName for the LuaLS download. This is only used for asset matching by name (not as a local file path, since the archive path is now fixed), but it's inconsistent with the Clangd fix. Low risk because the fixed archive path (lua-language-server.${ext}) is what actually hits the filesystem.
• packages/opencode/src/lsp/server.ts line 1054/1492: asset.browser_download_url from GitHub releases API is passed directly to fetch() without URL validation (pre-existing, not introduced here). The PR correctly fixes the local path injection vectors; the SSRF surface from browser_download_url is a separate concern and out of scope for this PR.

Files Reviewed (7 files)

• .changeset/secure-external-downloads.md
• packages/kilo-docs/source-links.md
• packages/opencode/src/cli/cmd/github.ts
• packages/opencode/src/kilocode/security/github.ts
• packages/opencode/src/lsp/server.ts
• packages/opencode/src/util/archive.ts
• packages/opencode/test/kilocode/archive-security.test.ts
• packages/opencode/test/kilocode/security-github.test.ts

---

Overall assessment: The PR correctly addresses the three reported code-scanning alerts. The GitHubSecurity.attachment allowlist is well-designed — origin pinning, no query/fragment, and explicit UUID/numeric-ID pattern matching handle path traversal and SSRF vectors cleanly. The PowerShell env-variable approach for archive paths is the right fix. The clangd tag allowlist regex is conservative and appropriate for a version string.

Fix these issues in Kilo Cloud

---

_{Reviewed by claude-4.6-sonnet-20260217 · 1,730,931 tokens}

_{Review guidance: REVIEW.md from base branch main}