AmrDab/clawdcursor
We ran AmrDab/clawdcursor, a node project, in an isolated sandbox. It built and started, then exited with an error on startup. We observed no malicious behavior, credential access, or outbound exfiltration. Its score is held down by install-time network/shell execution.
Positive
The package.json contains a postinstall script that executes local node scripts. This is consistent with the project's documented installation requirements.
The application uses localhost ports (127.0.0.1:3847/3848) for agent communication, which is standard for local desktop automation tools.
Three agents — install-time, runtime, and payload — read the source in parallel and cross-verified. These are their inferences from reading the code; the runtime facts below are what actually happened when we ran it.
Agent analysis (code read, not a runtime observation): Reviewed docs/install.sh: the model took tool action but attached no narrative to this turn.
Agent analysis (code read, not a runtime observation): Reviewed native/build.sh: the model took tool action but attached no narrative to this turn.
Agent analysis (code read, not a runtime observation): Reviewed scripts/mac/get-ui-tree.sh: the model took tool action but attached no narrative to this turn.
Agent analysis (code read, not a runtime observation): The file `scripts/mac/find-element.sh` is a shell script designed to interface with macOS accessibility features via JXA (JavaScript for Automation) and `osascript`. Its stated purpose is to provide a cross-platform wrapper for UI element discovery, mapping macOS accessibility roles to a Windows-like schema. ### Static Analysis Observations * **Functionality**: The script parses command-line arguments, maps UI roles (e.g., "Button" to "button"), executes a companion JXA script (`find-element.jxa`), and uses a Python one-liner to transform the resulting JSON output. * **Suspicion Level**: Low. The script follows a standard pattern for cross-platform automation tools. It does not contain obfuscated code, base64 blobs, or suspicious network activity. * **Dependencies**: It relies on `osascript` (a standard macOS utility) and `/usr/bin/python3`. * **Potential Risks**: While the script itself appears benign, it acts as a wrapper for `find-element.jxa`. The security of this operation depends entirely on the contents of that JXA file. ### Detonation Plan I will detonate this script to observe its interaction with the system. 1. **Dependency Check**: Verify the existence of `scripts/mac/find-element.jxa` in the repository, as the shell script will fail without it. 2. **Execution**: Run the script in the sandbox with benign arguments (e.g., `-Name "Finder"`) to observe the `osascript` call and the subsequent data transformation. 3. **Scope**: Monitor for any unexpected system calls or attempts to access sensitive files (e.g., keychain, SSH keys) during the execution of the JXA script. I will now proceed to check for the existence of the companion file before detonating.
No outbound connection attempts were observed during this run.
A control probe confirmed the sandbox intercepts all egress (the microVM has no route to the real internet except the forge) and a direct UDP query was dropped (non-TCP egress contained). The detonation itself made no outbound connection attempts during this run.