Open Supermarkets: why it is not safe to use
We found sensitive account handling and a real delivery-slot booking action that can change account state without an extra confirmation step.
What we found
Our review did not find hidden instructions, undisclosed data sinks, hardcoded secrets, obfuscated code, or privilege escalation behavior in the inspected files. The main reasons this skill did not fully pass are narrower and specific.
First, the skill handles supermarket account access. It reads login details from environment variables, stores session files under the user's home directory, and its Tesco documentation recommends importing browser cookies. That is legitimate for the stated use case, but it is inherently sensitive because it involves credentials and authenticated sessions.
Second, checkout is relatively guarded because dry-run is the default and CLI checkout requires `--confirm`. However, delivery slot booking is a real state-changing action and our scan did not find an additional confirmation step for that action.
What to do instead
Use this skill only with an account you are comfortable connecting to automation, and review how credentials, cookies, and session files are handled before use. Prefer test or low-risk accounts where possible. Before enabling any booking flow, verify the exact command path and add your own approval step or manual review for delivery slot selection and booking actions.
Source: https://github.com/abracadabra50/open-supermarkets
We report what our security review found at the time we checked, with the goal of keeping people safe. Projects change; if a maintainer has since fixed this, we are glad to recheck it. Email hello@agentpod.com.