agent-inbox

The module is not overtly malicious in itself but implements high-risk behavior by invoking a run.sh script found in user-home locations and trusting its output. The primary threat is supply-chain / local tampering: if an attacker can modify ~/.pi/.../run.sh or ~/.agent/.../run.sh, they can execute arbitrary code and exfiltrate data when these functions run. Recommended mitigations: validate/sign the external script, install it to a fixed, controlled path, restrict or sandbox execution, avoid returning untrusted stdout directly to callers, and review why MEMORY_SERVICE_URL is cleared. Also fix the syntax error in the except block before deployment.

The module itself contains no obvious intentionally malicious payloads, but it exposes high-impact sinks (arbitrary process execution and shell execution) driven by untrusted inbox JSON fields. If an attacker can create or modify pending messages, they can achieve arbitrary command execution in project directories and leak sensitive data via logs. This is a significant security risk in adversarial settings; in trusted, controlled environments it may be acceptable but should be hardened. Immediate mitigations: disallow shell=True for test commands, whitelist allowed commands/models, secure inbox write permissions, and redact logs.

SUSPICIOUS: the core messaging purpose is coherent, but the skill’s footprint goes well beyond passive inbox handling by enabling automatic headless agent execution, arbitrary shell-based verification, and outbound webhooks to arbitrary URLs. The external CLI dependencies appear legitimate, so this is not confirmed malware, but it is a high-risk automation skill that can execute and transmit data with limited user confirmation.

This module implements a credential- and data-exfiltration pattern: it reads a local OpenAI-like token and user prompt and sends both to a non-official, lookalike endpoint (chatgpt.com/...). The request headers and payload mimic official OpenAI traffic, increasing the likelihood this is designed to harvest usable credentials. There is no obfuscation and no destructive payload, but transmitting long-lived tokens and account identifiers to an untrusted domain is a high-risk malicious behavior. Recommendation: Do not run this code where you store real credentials; treat tokens in ~/.pi/agent/auth.json as compromised if this script was present. Replace with official API calls or verify remote endpoint ownership before use.