Codex community ships Security plugin, Plannotator, and `dcg` hooks as third-party tooling forms

• Codex's recent hook and plugin plumbing created a real packaging surface for third-party tooling, with OpenAI's own Codex hooks docs describing PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit, and Stop, while the Codex releases page calls out plugin-bundled hooks and hook enablement state; that shows up immediately in doodlestein's dcg post and plannotator's Codex support post.
• reach_vb's Codex Security post introduced a five-step AppSec workflow, security scan, threat model, finding discovery, validation, and attack path analysis, that looks a lot like a packaged security review flow on top of Codex Security's own repo scanning product in OpenAI's docs.
• plannotator's integration post and plannotator's review screenshot show Codex getting a dedicated planning and diff-review surface, not just another terminal wrapper, with official positioning on Plannotator's site around plan annotation, structured feedback, and local code review.
• doodlestein's dcg announcement says dcg now supports Codex through a PreToolUse hook, and the project's agents doc lists Codex CLI as a supported target detected via CODEX_CLI=1.
• The weirdest sign that a community layer is forming is the pet ecosystem: kevinkern's pet instructions exposes installable pet skills, while petergostev's limits-ring mod turns the pet UI into a quota display.

You can read OpenAI's hook docs, skim the Codex Security docs, and check the Plannotator site for the review workflow. There is also an open Codex Desktop issue about hatch-pet not showing up in slash-command autocomplete, which makes the pet posts feel less like novelty and more like people already pushing into rough edges.

The common dependency across this burst is hook support. OpenAI's Codex hooks docs say Codex discovers hooks.json and config.toml hook config, supports PreToolUse, and lets installed plugins bundle their own lifecycle config. The Codex releases page adds that recent releases improved marketplace installation, plugin-bundled hooks, and hook enablement state.

That packaging layer is what makes these posts more interesting than one-off prompts or shell aliases. plannotator's Codex support post is explicitly about app and CLI integration, while doodlestein's screenshot shows dcg merging a PreToolUse Bash hook into ~/.codex/hooks.json.

The security pack is the cleanest example of structure emerging around Codex. reach_vb breaks it into five workflows:

1. Security Scan
2. Threat Model
3. Finding Discovery
4. Validation
5. Attack Path Analysis

That map lines up with OpenAI's Codex Security overview, which says the product helps teams find likely vulnerabilities with repo-specific context, reduce noise through validation, and remediate issues in connected GitHub repositories. The tweet's extra move is packaging those steps as reusable skills inside the Codex UI rather than leaving them as an abstract product promise.

Plannotator is not pitching model quality. It is pitching a review surface. The official Plannotator site describes plan annotation before execution, full diff review for agent-written code, structured feedback back to the agent, and local-first operation across Claude Code, Codex, Copilot, Gemini, OpenCode, Pi, and VS Code.

The recent posts fill in the Codex-specific layer. According to plannotator's integration post, Codex app and CLI now support three skills:

• plannotator-annotate, annotate any file
• plannotator-last, annotate the last agent message
• plannotator-review, integrated code review

The release cadence also shows the tool getting deeper rather than just broader. plannotator's 0.19.5 post added an all-files viewer, keyboard shortcuts, and non-ASCII path support, while plannotator's 0.19.6 post made commands async so they no longer block the agent thread. In plannotator's async-design post, the author also notes the downside: if the agent keeps moving, /plannotator-last can lose message context and /plannotator-review diffs can drift out of sync.

dcg, short for destructive command guard, sits at the other end of the workflow. Instead of helping humans review plans or code after an agent thinks, it blocks risky commands before execution. In doodlestein's thread, the author says Codex support only became possible once Codex added the needed hook surface.

The project's agents documentation lists Codex CLI among supported agents and says detection happens through CODEX_CLI=1. doodlestein's integration screenshot adds a few Codex-specific details:

• dcg targets Codex CLI 0.125.0+
• the installer writes or merges ~/.codex/hooks.json
• denied commands exit with code 2 and report the reason on stderr
• existing hooks are preserved instead of overwritten

That is a small but important shift in how Codex is getting extended. Guardrails are moving from system-prompt folklore into hook-time protocol handling.

The pet posts are goofy, but they reveal a second kind of extension surface. kevinkern's instructions says pets can be installed as skills with skill-installer hatch-pet, toggled with /pet, and selected from Codex appearance settings. petergostev's video goes further and repurposes the pet UI to show quota rings for a 5-hour and weekly limit.

That already has edge cases. An open GitHub issue says /pet in Codex Desktop can get sent as a normal chat message instead of triggering the command, and another issue says installed hatch-pet skills may not appear in slash-command autocomplete. Even with those bugs, the pattern is obvious: people are treating Codex less like a fixed app and more like a modifiable client.