Is buddyh/narrator safe?

Both server.py and main.py are thin shims that resolve /Users/buddy/narrator and exec its Python venv. The actual narrator implementation — including all screen capture, Gemini API calls, and ElevenLabs integration — lives in a separate repository that is not part of this audited skill package. That external codebase is outside the trust boundary of this audit entirely. A malicious update to the upstream narrator repo would be executed on the next invocation without any OpenClaw re-audit.

The skill's core function is to capture the user's screen and send each frame to the Google Gemini Vision API for narration. This means any data displayed on screen — including passwords typed into terminals, secret keys visible in editors, private communications, confidential documents — is transmitted to Google's servers in real time. While this is the disclosed purpose of the skill, it constitutes systemic data exfiltration of everything the user views during the session.

Both main.py and server.py forward sys.argv directly to the external Python subprocess without validation or escaping. If an agent constructs a narrator invocation using untrusted input (e.g., from a webpage, email, or another skill), arbitrary arguments could be injected into the subprocess call, potentially altering behavior or passing dangerous flags to the upstream narrator.

The SKILL.md instructs agents to start narration with tmux new-session -d, creating a detached background process with no visible UI indicator. The session continues indefinitely until explicitly killed. A user who asks the agent to 'stop the narrator' may not realize the tmux session persists if the agent uses the wrong kill command. During active sessions, all screen content is continuously streamed to Google.

Runtime control is implemented via JSON files at /tmp/narrator-ctl.json and /tmp/narrator-status.json — predictable, world-writable paths on Linux/macOS. Any other process or skill running as the same user (or with write access to /tmp) could inject commands to change the narration style, enable profanity mode, or trigger other behavioral changes without the user's knowledge.

Every command in SKILL.md is hardcoded to /Users/buddy/narrator — a path specific to a single macOS user account. On any other system or for any other user, all commands in the skill documentation will silently fail or produce misleading error messages. An agent following these instructions would waste multiple tool calls attempting paths that cannot exist, and might be prompted to create directories or install at unintended locations.

Sensitive canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were opened and read (not written) during the monitoring period. Temporal analysis shows reads at audit timestamp 1771924457 (6 seconds before the git clone began) and again at 1771924485 (post-install). Both timings correlate with the Oathe audit framework's pre-install baseline capture and post-install integrity verification routines. Skill source code contains no references to any of these file paths. Canary integrity confirmed intact.

Network monitoring during installation shows only connections to 140.82.121.4:443 (GitHub), used for the git sparse-checkout clone of openclaw/skills. Pre-existing connections to Canonical servers were established before the audit began. No connections to attacker-controlled infrastructure, no DNS queries to suspicious domains, no unexpected process spawning.