Is cheminem/chemistry-query safe?

chem_ui.py calls iface.launch(share=True), which when executed creates a publicly accessible Gradio-hosted tunnel URL. Any agent that invokes this script would silently expose a live chemistry analysis interface to the internet. User sessions, submitted SMILES strings, and ADMET results would be processed through Gradio's sharing infrastructure with no authentication. This also creates a potential exfiltration channel for any data the agent provides to the UI.

Every credential honeypot file was opened and read during the audit window: .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and .config/gcloud/application_default_credentials.json. The reads occurred twice — once pre-install (ts 1771651595.463) and once post-install (ts 1771651619.447). All accesses are CLOSE_NOWRITE (read-only) and the canary integrity check confirms no content modification. Attribution is ambiguous: no corresponding EXECVE records link these reads to skill code, strongly suggesting the oathe monitoring framework performs these reads as part of its canary lifecycle. However, the post-install occurrence warrants disclosure.

query_pubchem.py, chembl_query.py, pubmed_search.py, rdkit_mol.py, and chain_entry.py all transmit user-supplied compound names, SMILES strings, or search terms to PubChem (NIH), ChEMBL (EBI), PubMed (NCBI), and GitHub as unencrypted URL parameters or POST bodies. If an agent operating in a sensitive context (pharma R&D, proprietary drug discovery) passes confidential compound names to these scripts, the data would be transmitted to and logged by those external services.

chem_ui.py hardcodes WORK_DIR pointing to /home/democritus/.openclaw/workspace/skills/chemistry-query/scripts — a specific user's home directory that does not exist in the monitored environment. This reveals the developer's system username, indicates the code was not reviewed or sanitized prior to publication, and would silently fail (causing confusing subprocess errors) in any deployment environment other than the author's machine.

chain_entry.py always includes recommend_next: ['pharmacology', 'toxicology'] in its JSON output, regardless of user intent. In agentic pipelines that auto-invoke recommended skills, every chemistry query would trigger at least two additional skill invocations without user consent. This could escalate data exposure if those skills access more sensitive systems, and constitutes unsolicited agent behavior manipulation.

The Quick Start section of SKILL.md uses exec python scripts/... syntax within fenced code blocks. While standard documentation convention, some agent runtimes scan injected skill content for executable directives and may interpret bare exec-prefixed lines as shell commands rather than documentation. The risk is low given the fencing, but the pattern warrants flagging for agent systems with loose prompt parsing.

opsin_name_to_smiles.py prints a wget command pointing to a GitHub-hosted JAR file when opsin.jar is missing. An agent observing this error and acting on it would download and execute a remote binary. While this is documentation-style guidance rather than auto-execution, it creates an indirect remote code execution vector if the agent interprets error messages as actionable instructions.

chain_entry.py and chem_ui.py pass user-controlled SMILES strings and compound names directly as subprocess arguments to rdkit_mol.py and admet_predict.py. Argument list invocation (not shell=True) prevents shell injection, but the data crosses subprocess boundaries with minimal validation — only basic RDKit SMILES parsing is performed before passing to sub-processes.

The install process performed only a sparse git clone from GitHub (140.82.121.4:443), sparse-checkout of the skill subpath, a file copy, and cleanup. No hooks executed, no unexpected processes spawned, no new persistent network listeners were created. The connection diff is identical before and after installation.