Is caioiscoding/omi-me safe?
https://github.com/openclaw/skills/tree/main/skills/caioiscoding/omi-me
The caioiscoding/omi-me skill is a legitimate but poorly implemented integration for the omi.me personal memory API, with no malicious prompt injection, no credential theft, and clean installation-time behavior confirmed by passing canary integrity checks and expected-only network connections. The primary concerns are a critical API URL variable bug that renders the skill entirely non-functional (OMI_API_URL set but API_URL used in curl calls), shell injection vulnerabilities from unquoted user input interpolation, plaintext API token storage with stdout exposure, silent system-wide symlink creation, and the inherent privacy risk of bidirectional data sync to a third-party cloud service. Users should evaluate whether sharing agent working context with omi.me is acceptable before installing.
Category Scores
Findings (8)
HIGH Shell injection via unquoted user input in omi-cli.sh -20 ▶
Multiple command branches in omi-cli.sh interpolate positional arguments ($*) and accumulated option variables ($data, $content, $title) directly into shell strings and curl -d payloads without quoting or escaping. An agent or user passing content containing shell metacharacters, backticks, or $() sequences could inject arbitrary shell commands during API call construction.
MEDIUM setup.sh creates persistent system-wide symlinks without user consent -10 ▶
The installation script unconditionally attempts to create symlinks for omi and omi-token in /usr/local/bin using 2>/dev/null || true to silently suppress failures. If the operation succeeds (e.g., agent runs with sudo or has write access), the skill scripts become globally accessible from any shell session and persist after the skill is uninstalled.
MEDIUM API token stored in plaintext and exposed via stdout -18 ▶
OMI_API_TOKEN is written to ~/.config/omi-me/token with chmod 600, but remains readable by any process running as the same user. The omi-token.sh get subcommand prints the full token value to stdout, meaning any agent capturing command output will have the token in its working context, conversation history, or logs.
MEDIUM Bidirectional sync of user data to third-party omi.me cloud service -12 ▶
The omi sync all command (and individual sync subcommands) transfers all stored memories, action items, and conversations to and from the omi.me API. If an agent operates on sensitive workspace content and then invokes sync, that content flows to a third-party cloud service. Users may not anticipate this data transit when asking an agent to manage tasks.
MEDIUM Undefined $API_URL variable renders all API calls non-functional -10 ▶
omi-cli.sh exports the variable OMI_API_URL (correct name) but the internal omi_api() helper references the variable ${API_URL} (different, never set). All curl invocations therefore use an empty base URL, producing calls to bare paths like /user/memories. This is a critical implementation bug that makes the skill entirely non-functional but was apparently never caught by testing.
LOW setup.sh silently captures environment-variable token without prompting user -5 ▶
If OMI_API_TOKEN is already present in the agent's environment when setup.sh runs (e.g., set for a different purpose or inherited), the script writes it to disk without informing the user. This could capture tokens from unrelated services if environment variable naming collides.
LOW Hardcoded absolute system path in SKILL.md setup instructions -12 ▶
The automated setup section of SKILL.md instructs users to run a script at /home/ubuntu/.openclaw/workspace/skills/omi-me/scripts/setup.sh, hardcoding both a specific username (ubuntu) and a specific workspace layout. On any other system this path does not exist, and an agent following these instructions literally will silently fail or produce confusing errors.
INFO Canary file accesses attributed to monitoring system initialization, not the skill 0 ▶
inotifywait and auditd recorded opens of honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCP credentials) at timestamp 04:45:47 — approximately 5 seconds before the git clone command was issued at 04:45:52. Sequential inode numbers (272633-272638) and timing are consistent with the oathe monitoring infrastructure creating and baselining these files. A second access group at timestamp 1771735564 aligns with the final integrity verification phase. No evidence these accesses originated from the skill under test.