Lixin2026
d5fe2e6a78
* feat(codex): add skill UI metadata * Use official Trail of Bits logo * fix: resolve code review findings for PR #175 Codex silently drops the icons as authored: its loader (codex-rs/core-skills resolve_asset_path) requires icon paths containing '..' to resolve under <plugin_root>/assets/, and the repo-root .codex/assets location fails that containment check. Verified empirically via codex app-server plugin/read: every iconSmall/iconLarge came back null; only brand_color applied. P1 fixed: - Vendor trail-of-bits-mark.svg into plugins/<name>/assets/ for all 38 plugins with skills and point every openai.yaml at ../../assets/trail-of-bits-mark.svg (the supported plugin-level shared asset pattern). Icons now resolve for marketplace installs too, since nothing escapes the plugin root. - Drop the .codex/ additions: .codex/skills/gh-cli/agents/ openai.yaml resolved nowhere (.codex/skills is not a Codex discovery root) and PR #173 removes the whole .codex/ tree P2 fixed: - Patch-bump all 38 touched plugins in plugin.json and marketplace.json so installed clients pick up the metadata Verified: - Static check replicating Codex's resolution algorithm: all 73 yaml files resolve under their plugin assets/ and exist - Live codex app-server probe: 71/72 loadable skills report resolved iconSmall/iconLarge and brand_color #D83A34 (claude-in-chrome-troubleshooting fails to load on main due to a pre-existing 64-char qualified-name limit, fixed by #173's rename; zeroize-audit's manifest mcpServers object is likewise a pre-existing Codex incompatibility fixed by #173) - validate_codex_skills.py, validate_plugin_metadata.py, prek all pass Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(codex): use skill-local icon assets --------- Co-authored-by: Dan Guido <dan@trailofbits.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Seatbelt Sandboxer
Generate a MacOS Seatbelt configuration that sandboxes the target with the minimum set of permissions necessary for it to operate normally.
Author: Spencer Michaels
When to Use
Use this skill when you need a targeted way to isolate a process on MacOS without using containers. This can be helpful for applications that are themselves trusted, but might execute potentially-untrusted third-party code as part of normal operation (such as Javascript bundlers), or that are at a high risk of supply chain attacks. Running such an application in a restricted sandbox helps reduce the "blast radius" if it is exploited.
This skill should NOT be used to run an untrusted process, since it requires running the target process to profile it in order to determine what permissions are actually needed.
What It Does
This skill provides a systematic four-step process for sandbox profiling:
- Profile a target application - Identify the actual set of permissions required for the application to run normally.
- Generate a minimal Seatbelt profile - Start from a default-deny profile.
- Iteratively expand permissions as needed - Test the application empirically to identify what calls fail with the minimal profile, and add the needed permissions until the application runs normally.
- Create helper scripts if needed - If the application has multiple subcommands that perform highly different functions (such as "serve" and "build" tasks), create separate Seatbelt configurations for each, and create a helper script to switch configurations based on how the target application is invoked.
Installation
/plugin install trailofbits/skills/plugins/seatbelt-sandboxer