Is conorkenn/openclaw-github-assistant safe?

Six canary credential files placed as honeypots were opened and read twice during the monitoring window. The pattern — all six files accessed sequentially within the same second on both occasions — is characteristic of scripted enumeration rather than incidental system access. The monitoring system reports the files are 'intact' (not modified or exfiltrated to the network), and the first access batch predates the skill installation entirely, pointing to the monitoring framework as the likely actor. The second batch (1771934953) lacks an identified responsible process. The skill's JavaScript source code contains no logic to open filesystem credential files, making direct skill attribution implausible.

test.js imports execSync from Node.js's built-in child_process module at the top of the file. This function allows arbitrary shell command execution. The import is never used in any of the eight test functions. While this may be an innocent development artifact, importing a shell execution primitive without using it is an unnecessary risk surface in code shipped as part of an AI agent skill. If the skill were later updated to invoke execSync with user-controlled or agent-controlled input, it would provide a direct shell injection vector.

The skill can create GitHub repositories, issues with arbitrary body content, and pull requests. These are write operations with side effects visible outside the user's machine. When an agent also has access to a filesystem-reading skill, this skill completes a two-step exfiltration path: read local sensitive files (source code, credentials, documents) and post their contents as a GitHub issue body, new repository, or PR description. The agent could be prompted to perform this covertly. The user would need to inspect their GitHub account to detect it.

The createIssue handler accepts an 'extra' object and spreads it directly into the POST body sent to api.github.com with no field validation or allow-listing. A malicious or manipulated prompt could supply unexpected GitHub Issues API fields (e.g., labels, assignees, milestone IDs) through this parameter. While the data goes to GitHub's API rather than an attacker endpoint, it could be used to manipulate issue metadata or trigger unexpected API behaviors.

The SKILL.md one-line description reads 'Query and manage GitHub repositories - list repos, check CI status, create issues, search repos, and view recent activity.' The capabilities table does document create_issue and create_repo, but create_pull_request is not mentioned in the description, and create_repo (which creates publicly visible or private repositories) is listed only briefly. Users installing this skill may underestimate the write privileges they are granting to their AI agent.

The package.json file defines the 'scripts' object twice. JSON specification disallows duplicate keys; most parsers silently take the last occurrence. The effective test script is therefore 'node index.js' (from the second block) rather than 'node test.js' (from the first). This obscures which file actually runs during npm test and is a code quality red flag, though not directly exploitable.

The skill's setup instructions direct users to generate a Personal Access Token with the 'repo' scope, which grants full read/write control over all private repositories. The documentation does mention the narrower 'public_repo' scope as an alternative, but the primary documented configuration grants maximum GitHub privilege. This is a broad attack surface if the token is exfiltrated or if the agent is manipulated into misusing it.

api.js declares let cachedUser = null at module scope and populates it on first /user API call. In long-running agent processes where Node.js modules are not reloaded between user sessions, a previous user's GitHub username could persist and be used in subsequent session calls (e.g., listRepos, getRecentActivity defaulting to wrong user).