redis-memory-system
ReviewAudited by ClawScan on May 17, 2026.
Overview
This is a coherent Redis memory tool, but it uses weak shared-key isolation and persistent auto-loading/cron behavior that could expose or reuse stored memories unexpectedly.
Install only on a private host or a properly secured Redis instance. Do not store secrets in this memory. Before running setup.sh, confirm you are comfortable with Redis being started, .bootstrap being modified, and an hourly crontab entry being added; remove those if you do not want persistent automatic memory behavior.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
On a shared machine or shared Redis instance, another local user or agent could potentially read or overwrite memory summaries by selecting the same Redis key.
The isolated script chooses the Redis memory key from an environment variable and shows no Redis AUTH, ACL, or account check. Any caller who can set REDIS_MEMORY_USER and reach the Redis instance can target another user's memory key.
USERNAME="${REDIS_MEMORY_USER:-}" ... KEY="memory:${USERNAME}" ... redis-cli HGET "$KEY" "$day"Use Redis ACLs/authentication, separate Redis instances or databases per user, and hardcoded protected per-user configuration rather than relying on key names or agent instructions for isolation.
Incorrect, stale, or maliciously written memory entries could influence future agent behavior across sessions.
The generated bootstrap file tells future sessions to read Redis records and use them as conversation context. Stored Redis text therefore becomes persistent agent context, but the artifacts do not show provenance checks, sanitization, or user confirmation before trusting that content.
如果 Redis 中有近期记录，阅读后作为对话上下文。
Treat Redis memory as untrusted notes, require confirmation before using it for important actions, and protect who can write to the Redis keys.
The skill can keep producing memory entries and preserving the Redis key in the background until the user manually removes the cron job.
The setup registers an hourly background cron job that keeps writing to Redis after installation. Because it refreshes the same key's TTL every hour, older hash fields may persist while the cron is active despite the skill's 7-day expiry framing.
echo "0 * * * * $CRON_SCRIPT") | crontab - ... redis-cli HSET "memory:$(whoami)" "cron:$TIMESTAMP" "auto ping at $TIMESTAMP" ... redis-cli EXPIRE "memory:$(whoami)" 604800
Make the cron job opt-in, document exactly how to disable or uninstall it, and avoid refreshing all historical memory when writing heartbeat pings.
Installing the skill may change the local system by adding and starting Redis.
The user-directed setup script may install a system package and start a Redis daemon. This is aligned with the Redis memory purpose, but it is system-mutating behavior that is not reflected in the registry requirements.
apt install -y redis-server 2>/dev/null || yum install -y redis 2>/dev/null ... redis-server --daemonize yes
Review the setup script before running it, run it only with the privileges you intend to grant, and prefer a documented install spec that declares Redis and cron behavior.