Module codex_app 

The Codex desktop app’s hook-plugin manifests, as templates.

Capturing the desktop app needs a Codex plugin: a manifest naming the plugin plus a hooks file subscribing a command to the five lifecycle boundaries crate::attribution::codex_app parses. Unlike pi’s extension (a fixed file, installed by copying), a Codex plugin is installed by Codex’s own plugin manager from a consumer-packaged source directory, and two of its ingredients are irreducibly the consumer’s:

• The hook command line. Each hook runs an executable that receives the lifecycle payload on stdin and reports it to the consumer’s local runtime. Which executable, and how it is located without depending on the app’s PATH, is deployment knowledge — the branded launcher script a consumer ships is exactly the part that cannot live here.
• The plugin’s identity. The name, description, and developer strings Codex shows the user must say who is actually asking for hook trust.

So the crate ships the manifests as templates: the JSON structure and the event set are crate-owned (and pinned against the attribution module’s event list), while the command and identity are slots the consumer fills through render_hooks_manifest and render_plugin_manifest. Both installers — a closed-source one today, a tapesctl installer later — render the same bytes around their own strings, which is the same anti-drift bargain the pi asset struck, adapted to a plugin that cannot be vendor-complete.

The templates carry no endpoint and read no environment: a hook plugin is inert until the rendered command does something, so the inertness obligation crate::plugin::GATEWAY_URL_ENV discharges for pi rests here on the consumer’s command instead.

Rendered manifests are still not an installed plugin. manager owns the rest: the marketplace wrapper that makes them installable, and the codex CLI invocation that installs them.

Modules

manager

Codex’s own plugin manager: the source layout it consumes and the codex subcommands that register and install from it.

Structs

HookPluginIdentity

The consumer-supplied identity a rendered plugin manifest presents to the user in Codex’s plugin UI.

HookPluginTemplates

The two manifests a consumer packages into its plugin source directory, as the registry hands them out.

Constants

CODEX_APP_TEMPLATES

The Codex desktop app’s manifest templates.

HOOKS_MANIFEST_TEMPLATE

The hooks manifest template — hooks/hooks.json in the packaged plugin.

HOOK_COMMAND_SLOT

Slot in HOOKS_MANIFEST_TEMPLATE that a consumer’s hook command line replaces. The slot is the entire JSON string value, so substitution is JSON-escaped by render_hooks_manifest; a consumer never edits the template text itself.

PLUGIN_MANIFEST_TEMPLATE

The plugin manifest template — .codex-plugin/plugin.json in the packaged plugin. Identity fields are slots for HookPluginIdentity; the manifest deliberately registers no tool, app, or skill, so an installed plugin is hook-only by construction.

Functions

render_hooks_manifest

Render the hooks manifest with the consumer’s hook command line.

render_plugin_manifest

Render the plugin manifest with the consumer’s identity strings.

shell_quote

value as a single POSIX shell word.