Git Version Control

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:46 AM UTC
• Version: 1.0.0

Overview

This is a legitimate Git checkpoint skill, but it needs Review because it normalizes broad staging and destructive rollback of core OpenClaw configuration.

Install only if you are comfortable with an agent making local Git commits and confirmed hard resets inside `~/.openclaw`. Before use, prefer an allowlist of intended configuration paths, inspect staged files and diffs before committing, expand secret exclusions, and require explicit confirmation plus a backup or safer reset option before any `git reset --hard`.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:51

Finding

Broad Git Staging May Persist Sensitive Files in Repository History

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 51–56
Vulnerability Type: Unsafe broad staging of configuration files
Risk Level: Medium

Vulnerable Code

bash

cd ~/.openclaw

# Check current status
git status

# Add all tracked files (respecting .gitignore)
git add -A

# Create commit with descriptive message
git commit -m "checkpoint: {description of pending change}"

The same unsafe staging command is repeated in the documented implementation and quick-reference workflow:

text

2. Run: git add -A
3. Run: git commit -m "checkpoint: {description}"

The proposed .gitignore protection at lines 158–176 is incomplete:

gitignore

# Session logs (volatile)
*.jsonl
*.jsonl.lock
*.jsonl.reset.*

# Databases (volatile)
*.sqlite
*.sqlite-journal

# Credentials (sensitive)
credentials/
*.pem
*.key

# Temporary files
*.tmp
*.temp
.DS_Store

# Logs
logs/

# Delivery queue
delivery-queue/

Technical Analysis

git add -A stages all changes under the repository, including untracked files that are not matched by .gitignore. The documented ignore rules protect only a limited set of credential locations and extensions. They do not account for common secret-bearing files such as .env files, token files, cloud-provider credentials, authentication configuration, or sensitive JSON and YAML documents.

Consequently, the assertion that credentials are excluded from version control is not reliably enforced. A sensitive file stored anywhere under ~/.openclaw/ outside the listed patterns can be added to a checkpoint. Once committed, deleting the working-tree copy does not remove the secret from prior Git objects and commit history.

This is an insecure configuration-management practice rather than evidence of intentional exfiltration. The reviewed files contain no network transmission or repository push instruction.

Attack Path

1. A user, another skill, or a local process creates a secret-bearing file under ~/.openclaw/ ...[truncated 1320 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace git add -A with explicit allowlisted paths containing only the configuration files intended for checkpointing. For example:

   bash

   git add -- \
     workspace/SOUL.md \
     workspace/AGENTS.md \
     workspace/USER.md \
     workspace/IDENTITY.md \
     workspace/skills \
     workspace/memory \
     openclaw.json \
     cron/jobs.json
   

2. Before every commit, inspect the exact staged file list and staged diff:

   bash

   git diff --cached --name-only
   git diff --cached
   

3. Reject suspicious filenames and locations before committing, including .env*, token or credential files, private keys, cloud-provider configuration, authentication caches, and secret-bearing configuration overrides.

4. Expand .gitignore defensively, while recognizing that ignore rules are not a substitute for an explicit staging allowlist. Suggested patterns include:

   gitignore

   .env
   .env.*
   *credentials*
   *secret*
   *token*
   .aws/
   .config/gcloud/
   .azure/
   

5. Run a secret scanner against staged content before each checkpoint and abort the commit if likely credentials or private key material are detected.

6. Detect whether a sensitive file is already tracked, because adding it to .gitignore does not stop Git from tracking an existing indexed file. Remove such files from the index and rotate any exposed credentials.

7. If a secret has already been committed, rewrite repository history using an appropriate history-cleaning tool, delete obsolete Git objects where necessary, and rotate the affected credential immediately.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (8)

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 95% confidence

Finding

Recommending git reset --hard as the default rollback mechanism is dangerous because it irreversibly discards uncommitted changes and can cause data loss if invoked in the wrong context. In an agent skill, this is especially risky because an automated workflow may choose the destructive option too readily during recovery operations.

Content

Scanner excerpt · SKILL.md (reported line 104)May include surrounding context.

md

|--------|---------|--------|
| Soft reset | `git reset --soft HEAD~1` | Undo commit, keep changes staged |
| Mixed reset | `git reset --mixed HEAD~1` | Undo commit, keep changes unstaged |
| Hard reset | `git reset --hard HEAD~1` | Completely undo commit and changes |

**Recommended default**: `--hard` for full rollback

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 93% confidence

Finding

The skill instructs execution of git reset --hard {commit-hash}, a destructive command with a parameter that determines how far state is rolled back. If the wrong commit is selected or the action is triggered with insufficient validation, the agent can delete legitimate work and revert critical configuration unexpectedly.

Content

Scanner excerpt · SKILL.md (reported line 119)May include surrounding context.

md

"Rollback to commit X? This will discard: {list changes}"
   
3. Execute rollback
   git reset --hard {commit-hash}
   
4. Report result
   "✓ Rolled back to commit abc1234"

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 91% confidence

Finding

Although presented as an example, it normalizes use of git reset --hard to a specific commit, which remains a destructive operation. In a skill intended for agents, examples shape implementation behavior, so this increases the chance of unsafe rollback practices and accidental loss of local changes.

Content

Scanner excerpt · SKILL.md (reported line 132)May include surrounding context.

git log --oneline -5

Show: abc1234 checkpoint: before skill install

def5678 previous config

git reset --hard abc1234 Output: "✓ Rolled back to 'before skill install' (abc1234)"

text

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 96% confidence

Finding

Listing git reset --hard HEAD~1 as the quick-reference rollback command encourages one-step destructive undo without adequate inspection or safeguards. Quick-reference sections are likely to be copied directly into agent behavior, making accidental data loss more likely.

Content

Scanner excerpt · SKILL.md (reported line 282)May include surrounding context.

md

| Action | Command | Alias |
|--------|---------|-------|
| SAVE checkpoint | `git add -A && git commit -m "checkpoint: {desc}"` | `save` |
| ROLLBACK | `git reset --hard HEAD~1` | `rollback` |
| View history | `git log --oneline -10` | `history` |
| Check status | `git status` | `status` |
| Compare diff | `git diff HEAD` | `diff` |

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 90% confidence

Finding

This example session again demonstrates git reset --hard as the execution step, reinforcing destructive rollback as standard practice. Even with a confirmation prompt, the skill lacks stronger guardrails such as backup creation, diff preview, or limiting rollback targets, so misuse can still cause substantial configuration loss.

Content

Scanner excerpt · SKILL.md (reported line 318)May include surrounding context.

"Rollback to abc1234? This will remove the newly installed skill."

3. Execute $ git reset --hard abc1234 ✓ Rolled back successfully

text

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 60% confidence

Finding

Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Content

Scanner excerpt · SKILL.md (reported line 43)May include surrounding context.

md

## Core Operations

### 1. SAVE - Create Checkpoint

Create a git commit before making sensitive changes. This provides a recovery point.

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 55% confidence

Finding

Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Content

Scanner excerpt · SKILL.md (reported line 88)May include surrounding context.

md

---

### 2. ROLLBACK - Restore Previous State

Revert to a previous commit when issues occur.

Autonomous Decision Making

Medium

• Category: Excessive Agency
• Confidence: 75% confidence

Finding

Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Content

Scanner excerpt · SKILL.md (reported line 263)May include surrounding context.

md

### ❌ Avoid

1. **Don't rollback without confirmation**
   - Hard reset destroys uncommitted changes
   - Always warn user about data loss