Summary

• Problem: When pipeline(readable, file) fails in downloadFile() (src/agents/skills-install-download.ts), the write stream is destroyed by pipeline but the partial file at destPath is left on disk.
• Why it matters: Leftover partial files waste disk space and can cause confusing state on retry.
• What changed: Wrapped the pipeline call in a try-catch that destroys the write stream (if not already destroyed) and unlinks the partial file before re-throwing.
• What did NOT change (scope boundary): No other files modified; no changes to download logic, archive extraction, or error reporting.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related: same pattern as PR Clarification for clawd.md #6 fix for src/commands/signal-install.ts

User-visible / Behavior Changes

None. The download still fails with the same error; the only difference is that partial files are cleaned up.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: any
• Runtime/container: Node 22+

Steps

1. Trigger a skill download where the network stream fails mid-transfer (e.g., timeout or connection reset).
2. Observe the destination path after the error.

Expected

• The partial file at destPath is removed after the download failure.

Actual (before fix)

• The partial file remains on disk.

Evidence

• Trace/log snippets: Code inspection confirms pipeline rejects on stream error, leaving the file behind. The added try-catch unlinks the file in the error path.

Human Verification (required)

• Verified scenarios: Code review of the error path; confirmed pipeline from node:stream/promises rejects and destroys streams on failure but does not unlink files.
• Edge cases checked: File not yet created (unlink silently caught), write stream already destroyed by pipeline (guard with !file.destroyed).
• What you did not verify: Live network failure scenario.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert the single commit.
• Files/config to restore: src/agents/skills-install-download.ts
• Known bad symptoms reviewers should watch for: If unlink itself throws unexpectedly (mitigated by .catch(() => {})).

Risks and Mitigations

• Risk: unlink could race with another process using the file.
  • Mitigation: The file is a temporary download artifact scoped to this function; no other code references it until downloadFile returns successfully.

Generated with Claude Code

Greptile Summary

Added try-catch around pipeline call in downloadFile() to clean up partial files when downloads fail. When pipeline rejects due to stream errors (timeout, connection reset), the write stream is destroyed and the partial file at destPath is unlinked before re-throwing the error.

• Guards file.destroy() with !file.destroyed check since pipeline already destroys streams on failure
• Uses .catch(() => {}) on unlink to silently handle cases where the file doesn't exist yet
• No other changes to download logic, extraction, or error reporting

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The change is a targeted bug fix that adds proper cleanup without altering core logic. The error handling is defensive (checks !file.destroyed, silent catch on unlink), and the fix follows Node.js stream error handling best practices. The change is well-scoped to a single function and maintains backward compatibility.
• No files require special attention

_{Last reviewed commit: e480afd}