other
- Location
scripts/meta-planner.py:199- Finding
Private workspace memory can be published to an external platform
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill needs Review because it can direct an agent to read local workspace memory or intelligence files and publish derived content externally without clear approval controls.
Install only in a contained workspace and treat this as an automation skill with external posting authority. Review PROJECT.yaml files before use, avoid giving it access to private memory or internal intelligence directories, and require a human preview before any browser-based publication.
scripts/meta-planner.py:199Private workspace memory can be published to an external platform
scripts/meta-planner.py:209Internal intelligence files can be read and published externally
scripts/meta-planner.py:126Project metadata is interpolated into a privileged agent prompt without isolation
SKILL.md:116Free-form workflow entries are treated as executable agent instructions
scripts/edit-project.py:21Unsanitized project identifiers allow directory traversal and configuration overwrite
SKILL.md:18PyYAML is installed without a version or integrity constraint
The declared description presents a workflow execution engine/scheduler for project tasks. The supplied code does something materially different: it is a human-in-the-loop project configuration editor. Its primary behavior is displaying and modifying project configuration text, not executing workflows. Several key declared behaviors are absent, including parsing workflow structure, sequential execution of workflow steps, and writing execution records to memory/executions.json. It also accesses the project file via a fixed ~/.openclaw/workspace/projects path instead of the runtime-determined workspace/project path described. Finally, despite the filename PROJECT.yaml, it reads and writes using json.load/json.dump, which is inconsistent with the declared YAML-based project configuration handling. This is a clear description-behavior mismatch.
The declared description presents a generic per-project task execution system: load one PROJECT.yaml, parse meta/content/target/constraints/workflow, execute workflow steps sequentially, and log results to memory/executions.json. The supplied code instead acts as a global meta-planner for publication scheduling. It enumerates enabled projects under a hardcoded workspace, reads history.md posting logs, checks an external intel state file, computes posting cadence/status, and emits a natural-language prompt instructing an agent how to choose and publish content for specific projects. There is no implementation of workflow.step_by_step execution, no parsing or use of content/target/workflow fields for task execution, and no writing to memory/executions.json. The accessed resources and primary purpose are materially different from the declared behavior.
The declared description presents an agent-native task execution engine: read PROJECT.yaml, parse several sections including workflow, execute steps in order, and persist execution records. The supplied code instead acts as a reporting/status utility for publishing projects. It enumerates enabled projects from a fixed ~/.openclaw/workspace-zsxq/projects path, reads constraints such as daily_max/daily_min/source_project, inspects history.md and republished.json to count today's posts and republished items, and prints status summaries for 'run-projects' or 'status' commands. There is no workflow execution, no step runner, no writing of executions.json, and no runtime path resolution logic matching the description. The primary purpose is therefore materially different from the declared task scheduler behavior.
The code opens PROJECT.yaml but parses it with json.load, creating a mismatch between documented format and implementation. This can cause parsing failures, denial of service for scheduling, or unsafe assumptions if malformed or attacker-crafted content is introduced and the planner silently skips projects or behaves unpredictably.
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
- Agent自主决策,不要问我
"""
return prompt
def main():
"""Meta-Planner入口"""
The manifest and agent instructions describe a task scheduler that reads PROJECT.yaml, parses workflow definitions, executes workflow.step_by_step sequentially, and records execution to memory/executions.json. In this file, the main runtime path merely enumerates projects, reads posting-history metadata, computes pending counts, and prints status; it never parses workflow content, executes steps, or writes execution records.
The skill describes shell commands, filesystem reads/writes, and workspace-wide logging, but declares no explicit tool scope or permission boundaries. In an agent environment, this can cause the skill to run with broader-than-necessary capabilities, increasing the chance of unintended file modification, command execution, or access to unrelated workspace data.
The skill instructs the agent to execute workflow steps and record results to project memory without clearly warning that it will modify project data. In agentic systems, silent write behavior increases the risk of unintended state changes, destructive actions, or compliance issues when users believe the skill is read-only or purely advisory.
The documentation first states that all PROJECT.yaml paths are relative to project root, then later authorizes absolute and home-directory paths. This inconsistency makes it easier for downstream implementations or agents to honor the more permissive rule, which can lead to out-of-scope file access and bypass of intended path restrictions.
The path resolution rules explicitly permit absolute paths and home-directory paths even though the skill is framed around project-root-relative files. That weakens containment and allows a PROJECT.yaml or workflow step to reference files outside the project boundary, enabling unauthorized reads or writes elsewhere on the host or workspace.
The skill appends execution details to a workspace-wide global log file, but this side effect is not clearly surfaced in the high-level description. Hidden cross-project writes can leak project identifiers, statuses, and paths, and they broaden the blast radius from a single project to the whole workspace.
This file contains natural-language instructions, examples, and interactive prompts exclusively in Chinese, including the tool description and workflow. Under the policy, forcing a specific language without offering a user choice or documenting a justified locale constraint is a natural-language policy violation.
The module docstring says the tool reads and modifies PROJECT.yaml, and load_project/save_project are documented as loading and saving the project. However, the code uses json.load and json.dump on that .yaml file path, which contradicts the stated behavior and would not preserve or correctly handle YAML-formatted project files.
The file-level description and all user-facing prompt content are written exclusively in Chinese, and the generated instructions require downstream agents to report progress and results in Chinese. There is no user opt-in, language selection mechanism, or documented reason that this skill must operate only in Chinese, which creates a locale-policy concern.
The script hardcodes workspace and project locations under the user home directory instead of deriving them at runtime from the manifest rules. This can make the agent operate on the wrong workspace, bypass intended sandboxing, and unexpectedly access or modify data outside the declared project scope.
The meta-planner reads workspace-wide state from ~/.openclaw/workspace/intel/state.json, which bypasses the skill’s stated per-project execution model and expands data access beyond the current project root. In an agent setting, this weakens isolation boundaries and can cause cross-project data leakage or decisions based on unrelated sensitive workspace contents.
The docstring presents this function as the scheduler entrypoint, yet its behavior is limited to status aggregation and console output. Given the surrounding skill intent, this documentation is misleading because it frames a reporting routine as the operative scheduler without executing workflows or recording runs.
The package and skill descriptions are written in Chinese, and the manifest does not indicate that the skill is region-specific or that users can choose another language. This can violate language/locale policy expectations when skills are expected to be usable without forcing a specific language absent opt-in or justification.
The file's primary natural-language documentation is entirely in Chinese, including the title and operational descriptions, with no indication that language choice is configurable or intentionally region-specific. This can violate a language/locale policy when users are not offered an alternative or explicit opt-in.
No suspicious patterns detected.