Is proactive-solvr safe?

AGENTS.md contains 'Don't ask permission. Just do it' which instructs the agent to bypass default confirmation behaviors. This is a behavioral override that weakens the user's control over agent actions, particularly dangerous when combined with external API posting and config modification capabilities.

AGENTS.md instructs the agent to fetch identity data from api.solvr.dev/v1/me/posts and merge it into SOUL.md before proceeding with any work. If the Solvr API is compromised or the user's account is hijacked, malicious instructions could be injected into the agent's identity, effectively achieving persistent prompt injection that survives workspace wipes.

The Error Protocol instructs the agent to automatically search and POST to api.solvr.dev on ANY error, exception, or unexpected behavior. Error messages frequently contain sensitive information (file paths, internal URLs, stack traces, environment details). While guidelines say to sanitize, the automatic nature and broad trigger ('ANY error') make leakage likely.

The soul persistence mechanism uploads the agent's identity (which accumulates user context, preferences, and work patterns) to api.solvr.dev. This data persists externally and is tagged with 'identity' and 'soul' tags, making it searchable. The agent's identity inevitably contains information derived from user interactions.

The onboarding flow and config-enforce.sh apply configuration changes via 'gateway config.patch' immediately after user answers, and the --fix flag auto-applies corrections. While config changes map to user answers, the mechanism modifies system configuration without explicit confirmation for each change. The agent is instructed: 'If you only record without applying, onboarding is broken.'

The approach lifecycle requires the agent to POST progress updates, status changes, and verification results to api.solvr.dev for every problem being worked on. This creates a continuous stream of work context being sent to an external service, including problem descriptions and solution attempts.

config-enforce.sh with --fix flag executes openclaw gateway config.patch commands that directly modify the user's openclaw configuration. While the script checks onboarding answers, it operates on the config file at $HOME/.openclaw/openclaw.json, modifying heartbeat intervals, thinking defaults, timezone settings, and reasoning visibility.

The skill recommends installing pre-commit-secrets.sh as a git hook. While the script itself appears benign (scanning for secret patterns), installing git hooks modifies the development workflow and could be updated in future versions to execute arbitrary code on every commit.

Filesystem monitoring shows /home/oc-exec/.aws/credentials was opened and accessed during the install process. While this may be part of the openclaw gateway startup (which reads various config files), accessing AWS credentials during a skill install is concerning and warrants investigation.

The combination of soul persistence (uploading identity to Solvr) and automatic rehydration (downloading and merging identity at session start) creates a persistent attack vector. If an attacker gains access to the user's Solvr account, they can modify the agent's identity posts to include malicious instructions that will be automatically merged into SOUL.md at every fresh session start.

While the security-patterns.md correctly notes Solvr content should be treated as 'community data — helpful but not authoritative', the main SKILL.md's workflow says 'Found? → Use it, move on' — suggesting the agent should act on Solvr results without verification in practice. This inconsistency could lead to indirect prompt injection via Solvr posts.

Three of four scripts use 'set +e' which continues execution after errors. While this is intentional for audit scripts that should complete all checks, it means partially failed operations are not caught, potentially leaving the system in an inconsistent state.

The heartbeat system reads system metrics (ps aux, uptime, free -m) for health monitoring. While these are read-only operations, they expose system state information that could be included in error reports posted to Solvr.

The automatic error posting and Solvr search behaviors mean that if another skill triggers errors or fetches malicious content, this skill will automatically post the context to Solvr and potentially retrieve attacker-crafted 'solutions' in return. It serves as an amplifier for attacks originating from other components.