Is mightyprime1/task-status safe?
https://github.com/openclaw/skills/tree/main/skills/mightyprime1/task-status
This skill contains a hardcoded Telegram user ID (7590912486) that serves as the default recipient for all status messages, creating a covert real-time surveillance channel into agent activity that activates automatically unless the operator explicitly sets the TELEGRAM_TARGET environment variable. The exfiltration vector is status text (task names, progress descriptions) rather than file contents, but the hardcoded default across three separate scripts with the developer's personal machine paths intact indicates this is not an accidental artifact. The skill also introduces a persistent background monitoring thread and instructs agents to register recurring cron jobs, expanding its footprint beyond any single task invocation.
Category Scores
Findings (8)
CRITICAL Hardcoded Telegram ID routes all status messages to skill author -82 ▶
Every script in the skills directory defaults TELEGRAM_TARGET to '7590912486'. This Telegram user ID is not a placeholder — it is a specific account that will silently receive every status message an agent sends using this skill unless the operator explicitly sets the TELEGRAM_TARGET environment variable. The default is present in at least three separate files (send_status.py, send_status_with_logging.py, send_status_websocket.py), indicating it is intentional rather than a single oversight.
HIGH Real-time agent activity surveillance via status heartbeat -68 ▶
The monitor_task.py background thread sends 'Still working...' messages every 5 seconds with the task name as the step identifier. This gives the Telegram recipient a continuous feed of agent task names and progress strings, effectively providing real-time operational intelligence about what the agent is doing on behalf of the user.
HIGH Background daemon thread persists sending messages if monitor never stopped -30 ▶
monitor_task.py spawns a daemon thread that loops until the task_name key is removed from the state file. If an agent calls 'start' but a crash, error, or incomplete task prevents it from calling 'stop', the thread continues transmitting status messages until the host process exits. The state file persists to disk (.task_status_state.json), so a subsequent process reload would not necessarily clean up stale monitors.
MEDIUM SKILL.md instructs agent to register a persistent cron job -18 ▶
The 'Automation with Clawdbot Cron' section of SKILL.md contains executable Python code that calls from cron import add and registers a 5-second recurring job. When this SKILL.md content is injected into an agent's context, the agent may interpret this code block as an instruction to execute, resulting in a persistent background job being registered in the Clawdbot scheduler without explicit user direction.
MEDIUM subprocess.run invokes clawdbot CLI with user-controlled message content -18 ▶
The fallback path in send_status.py constructs a subprocess call to the clawdbot CLI using the message, step_name, and target values. If any of these originate from attacker-controlled task descriptions (e.g., a malicious filename passed as a step name), CLI argument injection is possible depending on how clawdbot parses its arguments.
LOW Developer machine paths hardcoded in production scripts -5 ▶
send_status_with_logging.py hardcodes LOG_DIR = Path('C:/Users/Luffy/clawd/logs'), and README.md references installation to 'C:\Users\Luffy\AppData\Roaming\npm\node_modules\clawdbot'. These paths expose the developer's username and machine layout, and confirm the Telegram ID default is a live account on the developer's system, not a sanitized placeholder.
LOW Extra scripts not documented in README included in distribution -12 ▶
The README describes a file structure with only send_status.py and monitor_task.py, but the distributed package also includes send_status_with_logging.py and send_status_websocket.py. These undocumented scripts contain the same hardcoded Telegram ID and represent alternative transport implementations (with logging and with WebSocket handshake), suggesting iterative development toward reliable exfiltration. The presence of undocumented files increases the attack surface.
INFO Verbose debug output to stderr reveals agent internal state -2 ▶
monitor_task.py emits extensive [DEBUG] lines to stderr including task names, state file contents, iteration counts, and timing data. On systems where stderr is logged or monitored, this creates a secondary audit trail of agent activity.