Add OpenClaw skill import system with security scanning

[emooreatx]

Summary

Implements a complete skill import system that allows users to import OpenClaw-format skills as CIRIS adapters. This includes parsing, security scanning, preview/review workflows, and adapter generation with a HyperCard-inspired card-based UI for skill creation and editing.

Key Changes

Backend Services

• Skill Parser (parser.py): Parses OpenClaw SKILL.md format (YAML frontmatter + markdown) into structured ParsedSkill objects, supporting multiple metadata namespaces (openclaw, clawdbot, clawdis)
• Security Scanner (scanner.py): Comprehensive threat detection based on real ClawHub malware analysis (Feb 2026), detecting prompt injection, credential exfiltration, reverse shells, cryptominers, typosquatting, and undeclared network access
• Skill-to-Adapter Converter (converter.py): Transforms parsed skills into complete CIRIS adapter directories with generated Python code, manifests, and installation steps
• Skill Builder (builder.py): HyperCard-inspired card system for skill creation with 6 card types (identity, tools, requires, instruct, behavior, install), supporting both form-based and raw JSON editing modes
• API Endpoints:
  • Skill import endpoint (skill_import.py) for preview, security scanning, and importing skills
  • Skill builder endpoint (skill_builder.py) for managing skill drafts and card-based editing

Mobile UI

• SkillImportDialog (SkillImportDialog.kt): Multi-phase dialog (paste → preview → result) with security findings display, skill metadata review, and import confirmation
• SkillImportViewModel (SkillImportViewModel.kt): State management for import workflows and imported skills list
• Data Models (SkillImport.kt): Kotlin data classes for preview data, import results, and imported skill metadata
• Integration: Added skill import screen to main app navigation and adapters screen

Infrastructure

• Tool Bus Enhancement (tool_bus.py): Added tool alias registration mechanism to support skill-defined tool name mappings
• Localization: Added 140+ new localization strings across 10 languages for skill workshop UI
• Comprehensive Tests: Full test coverage for parser, converter, builder, and scanner with real malware pattern detection

Notable Implementation Details

• Security-First Design: Every imported skill is treated as untrusted code with multi-layer defense (scanner → manifest validation → adapter sandboxing)
• Real Threat Patterns: Scanner detects actual attack vectors from documented ClawHub incidents (Snyk ToxicSkills audit, ClawHavoc campaign)
• Adapter Generation: Automatically generates valid CIRIS adapter Python code with proper tool registration, environment variable handling, and installation step management
• Card-Based UX: Follows HyperCard philosophy with simple form mode for casual users and advanced JSON mode for power users
• Polyglot Support: Handles multiple skill metadata formats and install methods (brew, npm, pip, apt, manual, download)

https://claude.ai/code/session_01361QLEDwCP5FrbykjoWi4n

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

In general, to fix uncontrolled path use you should normalize the user-provided path and ensure it is constrained to an expected safe root directory (or use a strict allow list or filename sanitizer). Here, req.local_path is meant for "CLI/desktop use", but it still comes from the HTTP body and is used directly as a Path that can point anywhere. We should introduce a safe base directory for local imports (for example, the current working directory or a dedicated configuration directory), normalize the joined path, and verify that the resulting path is within that base. This prevents traversal (..), absolute paths, and paths that escape the designated root, while preserving the ability to specify relative paths under that root.

Concretely, within _parse_skill_from_request in ciris_engine/logic/adapters/api/routes/system/skill_import.py, we will:

1. Define a constant LOCAL_SKILL_IMPORT_ROOT at module level, set to a safe base (e.g., Path.cwd() by default), with a comment explaining its purpose.
2. Replace the direct path = Path(req.local_path) with:
   • base = LOCAL_SKILL_IMPORT_ROOT.resolve()
   • candidate = (base / req.local_path).resolve()
   • A check that candidate is within base using candidate.is_relative_to(base) (Python 3.9+); if not, raise ValueError with a clear message.
   • Assign path = candidate.
3. Keep the existing logic (is_dir, is_file, read, etc.) but operate on this validated path.

This approach avoids changing external behavior for valid, in-root relative paths but blocks absolute paths and traversal outside the configured root. No new third‑party imports are needed; we only use pathlib.Path which is already imported. All changes are localized to the shown file and the _parse_skill_from_request helper.

In general, the fix is to validate and constrain any filesystem paths derived from user input before accessing the filesystem. Common patterns: (1) restrict to a known safe root directory and normalize/resolve before checking containment; or (2) if local_path is not intended for remote use, explicitly disallow it in these HTTP endpoints and only support it in trusted contexts.

Given the context (“Local file path (for CLI/desktop use)”), the least invasive and safest fix for this API layer is: when handling an HTTP request, explicitly reject the local_path mode with a clear error. That keeps existing behavior for skill_md_content and source_url intact and avoids any path-based file IO using user-controlled data over HTTP. If the codebase has other non-HTTP entry points that construct a SkillImportRequest with local_path directly (e.g., a CLI), they can still call _parse_skill_from_request safely because they won't go through these FastAPI routes.

Concretely:

• In both preview_skill_import and import_skill, before calling _parse_skill_from_request, check body.local_path. If it is set, raise an HTTPException (400) indicating that local_path is not supported via the HTTP API and that the caller must provide the SKILL.md content instead.
• No changes are needed inside _parse_skill_from_request; we keep the same behavior for trusted, internal callers and eliminate the tainted-flow path only for HTTP requests.
• All modifications occur within ciris_engine/logic/adapters/api/routes/system/skill_import.py at the two route functions around the existing try/except blocks.

In general, to fix uncontrolled-path issues you must constrain or validate any user-provided path before using it, typically by (1) defining a safe root directory, (2) resolving the user path against that root, (3) normalizing it (e.g., Path.resolve()), and (4) verifying that the final path is still within the allowed root. Absolute paths, traversal attempts (..), or paths escaping the root should be rejected.

For this specific code, the best single fix with minimal behavior change is:

• Introduce a helper function _resolve_local_path that:

  • Accepts the raw local_path string.
  • Resolves it against a configured base directory (e.g., an environment variable CIRIS_SKILL_IMPORT_ROOT or a default such as the current working directory).
  • Uses Path.resolve(strict=False) to normalize the path.
  • Verifies that the resolved path is within the base directory by checking resolved_path == base_dir or base_dir in resolved_path.parents.
  • Raises a ValueError with a clear message if the path is outside the allowed root or is otherwise invalid.

• Update _parse_skill_from_request so that instead of path = Path(req.local_path) it calls _resolve_local_path(req.local_path) and uses the returned safe Path. The rest of the logic (is_dir(), is_file(), read_text()) remains unchanged.

• Because we already import Path from pathlib, no extra third-party packages are needed. For reading an environment variable we can import os (standard library) at the top of the file.

Concretely, in ciris_engine/logic/adapters/api/routes/system/skill_import.py:

1. Add import os alongside existing imports.
2. Add a new helper _resolve_local_path(local_path: str) -> Path in the “Helper Functions” section before _parse_skill_from_request.
3. Modify _parse_skill_from_request to use _resolve_local_path instead of Path(req.local_path).

This ensures both alert variants (for the two endpoints using body) are addressed, since they both call _parse_skill_from_request.

---

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ffd0fa0299

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Attach converted install steps to generated tool metadata

The converter builds install_steps_code from metadata.install, but the generated ToolInfo never consumes that value, so imported skills lose all dependency installation guidance. In practice, skills that declare brew/pip/npm installs will appear to have no install steps, which breaks setup workflows for users and any UI that relies on ToolInfo.install_steps.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Preserve supporting file subpaths when writing adapter assets

Supporting files are flattened to Path(rel_path).name, so two files from different directories with the same basename overwrite each other (e.g., references/readme.md and scripts/readme.md). This silently drops content from imported skills and can alter execution context whenever filename collisions occur.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Carry install-card steps into ParsedSkill during draft builds

The builder discards user-authored install-card data by hardcoding metadata.install to an empty list when converting a draft to ParsedSkill. As a result, skills built from the card UI never include the install instructions users entered, even though the draft model captures them.

Useful? React with 👍 / 👎.