lean4-prove

SUSPICIOUS: the core proof-generation purpose is plausible and the Claude CLI/data flows are mostly consistent, but the overall footprint is broader than advertised and the required lean_runner container is an unverifiable executable dependency. The combination of Bash+Docker, external dataset ingestion, autonomous lab/queue behavior, and unclear container provenance makes this a high security-risk skill even without clear evidence of malware.

This module is a legitimate tool to extract lemma dependencies by compiling Lean sources inside a Docker container and persisting results to a local memory service. I found no direct embedded malicious Python code (no obfuscated payload, no hard-coded secrets, no direct network exfiltration). However, it executes untrusted code in an external container and delegates DB operations to a locally referenced helper script (run.sh) — both are trust boundaries that could be abused. Treat MEMORY_RUN and the target Docker container as untrusted components: audit their code/configuration, restrict container capabilities, and harden the runtime to mitigate possible exfiltration or privilege escalation stemming from compiling attacker-controlled code.

No explicit malicious code is present in this specification. However, the described design—sending prompts to LLMs and compiling their generated code inside Docker—creates multiple high-risk operational vectors if implemented naively. Primary risks: secret exfiltration to LLM providers, command injection via unsafe subprocess usage, and host compromise via insufficiently isolated containers or compromised lean_runner images. Implementation must enforce strict container sandboxing, prompt/error sanitization, safe subprocess usage, minimal logging of sensitive data, and image integrity verification to reduce these risks.