archify

No direct signs of intentionally malicious supply-chain behavior (e.g., exfiltration, credential theft, hidden backdoors) are present in this code fragment. However, it is a high-impact automation harness: it spawns and CDP-controls a real headless Chrome instance, navigates to a caller-provided local HTML artifact (file://), and executes page-context JavaScript via Runtime.evaluate against that artifact. The optional --no-sandbox behavior (root or ARCHIFY_CHROME_NO_SANDBOX=1) meaningfully increases risk if the artifact is attacker-controlled. Treat as low-to-medium malware likelihood, but elevated operational security risk when processing untrusted HTML.

No clear indicators of overt malware (no keylogging, no system data exfiltration to external domains, no reverse shell). However, the module can execute a child CLI using an executable/script path that may be caller-controlled via options.deliveryCli, and it serves HTML produced by that child directly to the browser. The combination of untrusted-influenced HTML delivery and a permissive CSP for the main page (script-src 'unsafe-inline') makes this a noteworthy security risk for XSS in the local preview context. Overall: likely benign for its intended purpose, but with important execution-content risks requiring strict control of options.deliveryCli and input content.

This dependency is strongly suspicious: it monkey-patches a core filesystem deletion API to cause a targeted, one-time fabricated EPERM error for directory basenames starting with '.archify-migration-'. Although the real deletion is invoked before throwing, the thrown error can mislead migration/cleanup logic and disrupt deployments or leave inconsistent state. No evidence of data exfiltration or remote control exists in this module, but the sabotage behavior poses a high security risk in a supply-chain context.