Is addozhang/google-tasks safe?

Both refresh_token.js and auth.py compute credential file paths by traversing three directory levels above the scripts/ subdirectory. In the intended OpenClaw workspace deployment layout (workspace/skills/google-tasks/scripts/), this resolves to the workspace root — an intentional design convention for sharing credentials across workspace-level skills. However, this design means the skill unconditionally reads from outside its own directory tree. In the audit environment (/home/oc-exec/skill-under-test/scripts/), the path resolves to /home/ rather than the skill or user home directory. The shell-based refresh_token.sh correctly scopes paths to $SKILL_DIR, creating a documented inconsistency that suggests the JS and Python scripts were not reviewed with the same scrutiny. Users installing this skill outside the intended workspace structure may unknowingly expose unexpected directories to the credential search path.

create_task.sh uses the bash source builtin to load google-tasks-config.sh, executing its contents with the same privileges as the calling script. The current config file contains only DEFAULT_LIST="Private" and is benign. However, any agent, skill, or process with write access to the skill directory can modify this file. The next time a user asks the agent to create a Google Task, the tampered config will execute arbitrary shell commands in the agent's session. This creates a persistent code execution vector activated by normal user behavior.

refresh_token.js constructs an OAuth authorization URL from values read out of credentials.json (client_id, client_secret, redirect_uris) and passes it to child_process.exec() using template literal interpolation: exec(${start} "${authUrl}"). While URLSearchParams is used to build authUrl (encoding most shell-relevant characters), the exec() pattern with a string partially derived from an external file is inherently risky. A maliciously crafted credentials.json with redirect_uri values containing characters that survive URL encoding (e.g., backtick, $()) could potentially achieve shell command injection on platforms where the open/xdg-open command is invoked.

The file scripts/auth.mjs is present in the installed skill directory and recorded in the filesystem baseline with a known hash, but its source content was not included in the evidence collection. The skill already ships three other authentication implementations (auth.py, refresh_token.js, refresh_token.sh). This fourth unreviewed entry point represents residual audit surface that cannot be cleared.

The skill documentation describes itself as 'lightweight bash scripts' and the main scripts (get_tasks.sh, create_task.sh, delete_task.sh) are indeed pure bash. However, the repository ships four distinct authentication implementations: refresh_token.sh (bash), auth.py (Python), refresh_token.js (Node.js CJS), and auth.mjs (Node.js ESM). Each additional runtime increases the install footprint, maintenance burden, and audit surface without adding distinct functionality for users who already have bash available.

inotifywait and auditd records show .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and gcloud application_default_credentials.json were opened during the monitoring window. Two access batches are present: the first at audit timestamp 1771908249 (approximately 04:44:09), which precedes skill installation at 1771908267 by 18 seconds — consistent with the audit harness establishing a canary baseline before install. The second batch at 1771908272 follows the completion of all skill inspection EXECVE commands — consistent with post-install integrity verification. No write syscalls or outbound network transmissions to these paths were observed from skill-attributable processes. Canary integrity check confirms all files unmodified.

The skill requests https://www.googleapis.com/auth/tasks (full read+write), stores the resulting token in token.json, and auto-refreshes it indefinitely. A compromised token or agent session grants the ability to enumerate all task list names and contents (potentially revealing sensitive personal and professional schedules), create tasks that sync to calendar apps (social engineering vector), or permanently delete all tasks across all lists. The token persists silently across sessions with no expiry enforcement in the skill's own code.

Two compounding behavioral risks: (1) The shell source pattern means a malicious skill that can write files in the workspace could plant a backdoor in google-tasks-config.sh that executes whenever the user asks the agent to create a task — a highly natural and frequent operation. (2) delete_task.sh accepts a list name and task identifier as arguments; if argument validation is bypassed or the agent is manipulated into passing crafted identifiers, legitimate user tasks can be irreversibly deleted. These risks are individually low but meaningful in adversarial multi-skill deployments.