loongsuite-pilot-ops

High-risk supply-chain installer behavior: it downloads and deploys an external package and runs npm install (untrusted code execution). It also persistently injects token-intercept wrappers into user shells and macOS launchd to preload local hook modules into external tools (qodercli/qoderwork/Claude Code). Even though no explicit exfiltration endpoint is visible in this fragment, the explicit token-interception/persistence patterns make this likely to enable credential/token collection. Verify the downloaded PACKAGE_URL trust, inspect $DATA_DIR/hooks/*.mjs/.js and any network calls, and review npm dependency provenance before use.

No explicit malware (e.g., reverse shell, credential harvesting from environment, or hardcoded exfiltration) is clearly demonstrated in this fragment. However, the code is a powerful supply-chain installer: it downloads and extracts an archive, executes JavaScript from the extracted content (probe and postinstall), runs npm install in the deployed package directory, and writes credentials into a persistent config. If the package or its dependencies were malicious or compromised, these execution points would enable harmful actions. Overall, the fragment presents medium-to-high supply-chain risk due to unverified code execution from downloaded artifacts, even though direct malicious logic is not visible here.

The fragment is primarily a persistence installer/manager that creates launchd/systemd/SysV autostart entries for a collector and an optional updater, including system-level installation capabilities. That persistence behavior is the main supply-chain security concern because it ensures long-running execution across reboots and increases impact if the underlying binaries/config are compromised. Within this fragment there is no clear evidence of network exfiltration, credential theft, cryptomining, or obfuscated malicious payloads; the embedded Node.js logic is limited to local JSON read/modify/write for trace span attributes with reserved-prefix rejection. Final malware assessment is uncertain because the actual behavior of loongsuite-pilot/run-updater is not present in this code excerpt.

This PowerShell wrapper primarily implements per-user persistence and automatic execution for a Node-based collector/updater using Windows Task Scheduler and a hidden VBScript launcher. It also includes a fallback that spawns powershell.exe with -ExecutionPolicy Bypass (hidden) to run node and redirect logs. While this is plausibly legitimate for an agent, the combination of scheduled-task persistence, hidden execution, watchdog triggers, and ExecutionPolicy Bypass are strong risk signals in a supply-chain context. No direct network exfiltration, credential harvesting, or system-destruction behavior is visible in this wrapper alone; those would be in the referenced JS entrypoints/scripts, which are not included here. Overall: medium suspicion of malicious capability due to persistence/stealth mechanics, but insufficient evidence of concrete malware within this snippet.

This updater is designed to execute remote, downloaded code (npm install and an optional postinstall script) and then deploy it as the active version. That is a classic high-risk pattern for supply chain attacks: if an attacker can tamper with manifest/package URLs or integrity metadata (sha256), they can achieve arbitrary code execution in the client environment. While the code includes an optional SHA-256 check, there is no visible signature-based verification or strict trust boundary enforcement in this snippet. Therefore, the behavior is potentially malicious or at least highly dangerous under compromise scenarios and should be reviewed for stronger authenticity guarantees and safe archive extraction.

No strong evidence of intentional malware/backdoor behavior in this module. It functions as a local telemetry logger that persistently writes rich chat and tool data (including system/user text, tool arguments, tool outputs, and error details) to JSONL files on disk. The primary security risks are (1) privacy/data leakage due to non-redacted logging of potentially sensitive content and (2) filesystem write-path control via an environment-variable-defined data directory. Availability risk may also exist due to synchronous file writes on high-frequency events.

Moderate concern: this module performs local persistence-style modifications (injecting managed blocks into user shell rc files and managing a macOS LaunchAgent/launchctl environment). It also executes local repair commands by spawning a Node binary with configurable install arguments. While marker/signature checks and cleanup suggest intended “self-healing” behavior, the use of eval in injected startup blocks and the power to write LaunchAgents and wrap user commands mean the impact could be severe if upstream configuration/targets are tampered with. Based on the fragment alone, it is not possible to confirm malicious payload delivery, but the security risk is elevated.

This module performs filesystem-based configuration deployment for hook/agent behavior (including writing “hooks” command entries into user settings JSON). The most suspicious aspect is the explicit environment-variable-controlled bypass that disables hook trust verification, combined with the potential to persist attacker-influenced command templates into tool-controlled hooks. No direct runtime code execution is shown in this snippet, but configuration poisoning/integrity weakening is a credible risk depending on how def.hook.hookCommand and def.hook.* are sourced/validated elsewhere.

该技能与其“安装/配置数据采集工具”的声明基本一致，没有明确的凭据窃取指令，且对 AK/SK 有避免转发的约束；但其核心安装路径依赖不可验证的 OSS 远程脚本并直接执行，且要求全权限、可代用户完成系统级安装与持续数据上报。整体更像高风险运维/遥测安装技能，而非确认恶意；结论为 SUSPICIOUS。

Medium-to-high supply-chain risk. The code downloads remote artifacts (potentially over HTTP), extracts tarballs using system tar without visible archive hardening, and then can execute install shell scripts from within package/pilot directories. Hashing is present but not shown as enforced against a trusted value/signature. If attacker influence exists over URLs, tarballs, or extracted contents, this can lead to arbitrary code execution via the install script and/or filesystem traversal via tar extraction.

The code itself is a script-generation/orchestration utility, but it creates high-risk execution flows: it generates bash that downloads and executes remote install scripts (including `curl https://cursor.com/install | bash`), executes base64-decoded per-agent probe script blocks, and allows arbitrary extra bash injection via `E2E_EXTRA_ENSURE_BASH`. If an attacker can tamper with environment variables or the agent-matrix.json (or upstream matrix data), this becomes a direct arbitrary code execution/supply-chain compromise vector. No clear evidence of steganography/obfuscation or direct theft is present in this snippet, but the supply-chain execution primitives are strong.

No direct evidence of JS-level malware, obfuscation, network exfiltration, or credential theft appears in this fragment; however, it tests a feature that persistently modifies .zshrc/.bashrc by injecting guarded shell code that includes eval-based deferred definitions to override/intercept a CLI/function. This capability is inherently high risk if mis-scoped or attacker-influenced. Based on the snippet alone (tests only), malicious intent is not proven; the security concern is the underlying eval + RC injection mechanism that should be carefully audited in the real implementation.

This module is designed to execute scenario-based shell scripts in a Docker environment and includes an explicitly dangerous remote execution pattern: it downloads a payload from INSTALLER_URL and pipes it directly into bash (curl -fsSL "$INSTALLER_URL" | bash). Because INSTALLER_URL and related parameters come from environment variables (and script content is assembled as executable shell), the main security risk is supply-chain/remote installer compromise or command injection if environment values are tampered with. No direct evidence of stealthy malware (e.g., keylogging, exfiltration to a specific domain, persistence mechanisms) is visible in this snippet, but the remote code execution capability makes the overall risk high for hostile environments.

This module is primarily an E2E configuration deployment utility that conditionally writes/merges local Codex and Claude proxy configuration files into the user’s home directory. It does not show overt malware behaviors like networking or exfiltration in the provided fragment, but it does: (1) execute a base64-decoded embedded Node helper to modify user config files, and (2) persist a proxy API key from environment variables to disk. The main security concerns are supply-chain/abuse risk from embedded code execution and secret persistence, plus potential unintended configuration corruption due to regex-based merge logic.

This module functions as a covert telemetry/recording interceptor: it globally patches fetch for /v1/messages requests, parses request 'system' instructions and streaming SSE response metadata (message id and time-to-first-token), and writes the captured content to local disk under an environment-derived intercept directory. While there is no explicit remote exfiltration in this fragment, the sensitive data capture plus global interception behavior makes this a high privacy/security concern and potentially malicious or unauthorized logging depending on the integrating application’s consent and controls.

High-risk privacy-invasive behavior: this module globally monkey-patches JSON.parse and JSON.stringify to capture and persist LLM system prompt content (verbatim, with minimal gating) and token-usage metadata to local JSONL log files. It also dynamically discovers and imports an in-app runtime after installing these hooks, making interception likely during the runtime’s operation. No network exfiltration is visible in this snippet, but the local logging of sensitive prompt content is itself a significant security and privacy concern.

No overt malware, obfuscated payloads, or data exfiltration behavior is evident in this fragment. However, the watchdog has a security-sensitive design: it executes an external restart script/binary determined by opts.loongsuitePilotBin or a default path under the user’s home directory, and on Windows it runs that script via PowerShell with ExecutionPolicy Bypass. If the script/binary path can be tampered with (write access to the default location or malicious configuration), the watchdog can be coerced into executing attacker-controlled code during restart attempts. Risk is therefore moderate and centered on integrity/trust of the restart target and operational logging/telemetry exposure.

This module is designed to execute arbitrary bash scripts provided via opts.script, captures their output, and writes logs/artifacts to disk. While consistent with e2e orchestration, it also includes a helper that kills specific processes and restarts a service, which could be harmful if the script/inputs are not tightly controlled. The main security concern is the high-impact execution sink (bash -c) and partial/heuristic secret redaction when writing artifacts. No explicit malware/backdoor mechanisms are visible in this snippet beyond the orchestrator behavior; however, misuse could enable sabotage or data exposure via artifact/log collection. Overall, this should only be used in trusted test environments with strict control over script content and output directories.

No explicit malware, exfiltration, or credential theft is demonstrated in this snippet; it is a Windows-only test harness. The main security-relevant concern is that it executes copied hook scripts via PowerShell using '-ExecutionPolicy Bypass', which reduces script execution safeguards, and the true behavior depends on the external hook assets (not shown here). This should be reviewed at the hook asset level, but based on this fragment alone the probability of malware is moderate and the most actionable risk is execution of potentially untrusted script content.

This module is a strong confidentiality/privilege-violation red flag: it covertly intercepts LLM request/response data by globally overriding JSON.parse and JSON.stringify, captures both token usage metadata and the full system prompt content, and writes them to a persistent local JSONL file under a hidden directory in the user’s home (or /tmp). While it does not demonstrate network exfiltration in this snippet, the local harvesting of system prompts and related metadata is highly suspicious and could enable unauthorized monitoring or later extraction. Further context (where this module is used, whether file access is expected, and whether users were informed) is needed for final policy decision, but the behavior pattern is not consistent with a benign dependency.

No direct evidence of classic malware behaviors (no network, no subprocesses, no obvious credential theft). However, the module loader performs dynamic import of a local dist/index.js path determined by unsanitized pointer-file contents and environment-influenced cache paths, without any integrity verification. If an attacker can write/poison the pointer files or influence the cache/data directories, this can enable arbitrary code execution within the Node process. Crash logs may also leak local error details to anyone with access to the log directory.

This module is a high-impact local loader that dynamically executes an on-disk updater module determined by (1) an environment-controlled cache directory and (2) unvalidated pointer-file contents. If an attacker can write to the cache/pointer file or influence LOONGSUITE_PILOT_CACHE_DIR, it can enable arbitrary code execution. No explicit network exfiltration or credential-stealing behavior is visible in this snippet; the primary risk is trust boundary violation leading to code execution from tampered local files.

No explicit malicious code is present in this Docker Compose YAML fragment (it is configuration-only). However, it materially increases supply-chain and execution risk by running a privileged container (privileged: true), injecting many high-value secrets/tokens into the container environment, mounting repository content, and including flags that plausibly drive network/authenticated actions and remote configuration writes. Treat the overall setup as high-risk until the Dockerfile and container entrypoint/scripts are reviewed to verify there is no exfiltration, backdoor behavior, or unnecessary privileged access.

This is an end-to-end test orchestration script with a significant security weakness: it uses eval to execute each line of a local .env.e2e file. If .env.e2e is modified or substituted by an attacker, it can lead to arbitrary command execution in the host runner context. No direct malicious payload (e.g., exfiltration/backdoor) is evident in the provided snippet, but the eval pattern combined with loading high-value credentials into the environment makes the overall security risk moderate-to-high for compromised configuration scenarios.

This wrapper is a sensitive launcher that conditionally injects a local “token intercept” module into the qodercli process using preload/import mechanisms (NODE_OPTIONS --import or BUN_OPTIONS --preload) and then executes qodercli with that instrumented environment. The wrapper alone shows no direct exfiltration, but it intentionally grants high-impact in-process visibility; actual maliciousness can’t be confirmed without reviewing qodercli-token-intercept.mjs.

No explicit malware is present in this snippet because it is only a Docker Compose service definition. However, the configuration is high-risk: it runs in privileged mode and injects many sensitive API keys/tokens into the container while mounting the project and E2E scripts. If the referenced runner script (run-l1.mjs) or scenario logic is compromised, this setup would significantly increase the likelihood and impact of supply-chain or data-exfiltration attacks. Further review of the referenced runner script and scenario/probe command handling is required.

This code is a high-risk command-construction helper: it converts caller-provided text directly into a bash execution payload by base64-decoding and running it with `bash -s`. There is no explicit evidence of malware (exfiltration/persistence) in this fragment, but the capability to execute arbitrary bash makes misuse with untrusted input a serious remote code execution risk. Security posture depends entirely on strict upstream trust/validation of `probeCmd` and the context in which the returned string is executed.

This fragment configures event-driven execution of an external shell hook script, with trust gated by a local marker in ~/.codex/config.toml and additional directives that may replace telemetry/instrumentation components. While no explicit malicious payload or network exfiltration is present in the configuration itself, the combination of (1) direct shell-script execution, (2) variable-based script path resolution via $PILOT_DATA, and (3) triggering on user prompt submission makes the hook surface security-sensitive and worth verifying end-to-end by inspecting the referenced script and the trust enforcement logic.

This fragment is a high-impact Cursor hook configuration: it enables execution of an external shell script on a wide range of sensitive agent and IDE lifecycle events and references a local history/log directory that could contain prompts, agent reasoning, and tool traces. The snippet itself shows no credentials, obfuscation, or explicit network endpoints, but it creates a strong delegation point where malicious telemetry or exfiltration could be implemented in the referenced shell script. Security review should focus on the integrity/provenance of $PILOT_DATA/hooks/cursor-loongsuite-pilot-hook.sh and how it handles event/context data and logs.

This JSON fragment is a hook/deployment configuration, not the executable payload. It directs event-driven execution of an external shell script (hookCommand) and includes command/instrumentation replacement directives. There is no direct malicious code in the provided fragment, but the indirection to an unseen script is a notable supply-chain risk that warrants reviewing the referenced hook script and any referenced OpenTelemetry/instrumentation behavior. Overall, malware is unproven here.

This fragment is not executable payload code; it is a high-sensitivity plugin-injection configuration that directs the host to load and potentially execute a local JavaScript module from file://$PILOT_DATA/plugins/mimo-code/plugin.mjs and to override specific plugin identifiers. While the snippet shows no explicit malicious behaviors (no network calls, credentials, or obfuscation), it exposes a supply-chain/tampering risk typical of runtime code loading. Security depends on whether the injected plugin artifact is protected (integrity pinning/signing), how $PILOT_DATA is provisioned, and whether permissions prevent substitution.

This JSON snippet is a hook/persistence-style configuration that instructs a runtime framework to execute a local shell script located under $PILOT_DATA/hooks and to redirect/override how the qoder command is invoked (via replaceHookCommands), triggered around the “Stop” event and influenced by local settings and JSONL history logs. The snippet itself contains no direct malware indicators (no secrets, no network endpoints, no inline payloads), but it creates a meaningful execution sink and interception pathway, making integrity of ~/.qoder and $PILOT_DATA/hooks/qoder-loongsuite-pilot-hook.sh the decisive factor. Review and verify the referenced script, filesystem permissions, and tamper-resistance before trusting this package/configuration.

This fragment is a hook/control-plane configuration that can trigger on the “Stop” event and ultimately execute external shell scripts from $PILOT_DATA/hooks, with additional command redirection via replaceHookCommands. The configuration itself contains no direct malware indicators (no secrets, no network destinations, no inline payloads), but it creates a high-impact execution pathway whose safety depends entirely on the content/behavior of the referenced .sh scripts and how the orchestrator uses the local settings and hook-jsonl history. Review the referenced shell scripts and the orchestrator’s command-rewriting logic for persistence, telemetry/exfiltration, and privilege-abuse behaviors.

This JSON module itself is non-executable configuration, but it materially enables shell-script execution by the host hook framework. It wires user-scoped settings (~/.qoderwork/settings.json) and local hook history logs ($PILOT_DATA/logs/qoder-work/history) into a hook that runs on the "Stop" event, executing scripts located under $PILOT_DATA/hooks/. The security risk is driven by the integrity/provenance of those referenced .sh files and how (or whether) the framework validates them; no direct evidence of malware exists within this snippet.

This fragment is not malicious code by itself; it is a configuration that enables a host-controlled plugin injection workflow. The primary security concern is that the injector is directed to load an external .mjs entrypoint from a runtime data directory and to create/modify the agent’s extensions configuration in the user’s home directory. If $PILOT_DATA/plugins/pi-coding-agent/index.mjs is tampered with or untrusted, it can result in arbitrary code execution by the agent. Verify the integrity/provenance of the referenced plugin module and ensure the plugin directory is protected against replacement.

This artifact is a hook configuration that delegates behavior to an external shell script executed at multiple sensitive lifecycle events, including user prompt submission, and it consumes local settings and JSONL event logs. The configuration itself shows no explicit malicious payloads or secrets, but it creates a high-impact execution sink outside the provided code, so the primary security risk is undisclosed behavior in $PILOT_DATA/hooks/qodercn-loongsuite-pilot-hook.sh (e.g., tampering, data collection, or exfiltration). Reviewing the referenced shell script and its trust boundaries/permissions is essential.