How we test
Four steps, the same for every tool. Untrusted code only ever runs inside a sandbox we can throw away.
1. Read the code first
Before anything runs, we read what the tool would run on your machine: install scripts, dependencies, post-install hooks, network calls, and anything that asks for keys or tokens. We check that the package names are the real ones and not look-alikes.
Unknown publisher, no execution. If we can't verify who publishes a repo, it gets this static review only. If something looks wrong, the tool goes to quarantine with the reason, and we never run it.
2. Install it, locked down
Tools from known publishers are installed in Docker or on a throwaway server, never on our own machine. Network access is off whenever the tool can work without it. We never give a tool real API keys or real accounts.
3. Give it real work
We test tools on tasks a real user would give them, not on the demo from the README. Every run is recorded on screen. We count what passed, what failed, how long it took and what it cost.
4. Write the verdict
Each tool gets three scores out of 5, then one call.
| Score | The question |
|---|---|
| Safe | What does it touch, what does it send out, and how much do you have to trust its publisher? |
| Works | Did it do the real tasks, and how often did it fail? |
| Worth it | Is it worth the setup time and the cost, compared to what you already use? |
- Install it: safe enough and does the job.
- Use with care: useful, with a real risk or limit you should know about.
- Skip it: unsafe, broken, or not worth your time.
What a verdict can't promise
A safety check lowers risk. It can't guarantee that any software is 100% safe, and a tool can change after we test it. Every case file shows the version we tested and the date. Always review code before you run it.