setup

No explicit stealer/backdoor logic is present in this module, but it contains a critical command-execution capability: evaluateCheck() runs arbitrary sh -c commands sourced from manifest-defined check strings. In a supply-chain setting where manifests/marketplace data can be influenced, this can become host-level RCE during plugin/hook evaluation. Additional amplifiers include hook enablement defaulting to true on config parse failures and the construction of bash/install command strings from unvalidated manifest/script fields. Overall, treat this code as security-sensitive and require strict trust/allowlisting or sandboxing for any manifest/marketplace-derived checks.

This code is a local process/launcher manager with readiness probing and some user-home setup. It does not show clear malware behavior in the fragment (no exfiltration, credential theft, or backdoor patterns). However, it has a meaningful security concern: it executes an external wrapper binary and runs local scripts via Bun, with the wrapper executable name controlled directly by environment variables and with process.env largely passed through. If an attacker can influence the environment or the resolved installation/cache roots, this becomes an execution-based supply-chain/local-compromise amplifier. Review helper functions that resolve roots and control environment integrity to reduce risk.

This code is a macOS auto-updater that downloads a DMG from a fixed remote endpoint, stages an app after verifying its code signature (and Gatekeeper only for production), and installs it by executing a generated bash script that kills the running app and swaps the .app bundle on disk. There is no direct indication of data theft or hidden exfiltration in this module, but the supply-chain and high-impact install mechanism are significant: if the distribution endpoint or update authorization/signing trust is compromised, the updater will fetch and attempt installation of attacker-controlled code (bounded by local verification). The channel-dependent Gatekeeper enforcement and reliance on mutable global staging state are additional security considerations.

This module is not performing stealthy malicious actions in the shown code, but it creates a significant supply-chain/security risk: it triggers server-side installation and upgrade of third-party plugins/skills by spawning external CLIs based on pack-derived dependency identifiers and a runtime requested by the caller. Because it also forwards the full process.env to child processes and provides no visible allowlisting/sanitization for dependency.source/name/marketplace, an attacker who can influence pack contents or packPath could cause unintended/arbitrary third-party code to be installed. Recommended review areas: trust boundaries for packPath and detected pack contents, strict allowlisting/validation for dependency.* fields, and minimizing environment propagation to child processes.