Hooks should support stable bundle/plugin context for reusable hook scripts #16466

What variant of Codex are you using?

CLI

What feature would you like to see?

Hooks should support stable bundle/plugin context for reusable hook scripts.

Today, Codex hooks have access to repo/session context like cwd, but they do not have a first-class way to locate assets that belong to the bundle or plugin they are associated with.

That becomes a problem for reusable hook integrations that need to read bundled assets such as skills, templates, or helper scripts.
This is specifically about reusable bundle/plugin-backed hook integrations, not arbitrary repo-local hooks.

Without stable bundle/plugin context, hook scripts have to rely on hardcoded install paths or path inference based on script location, which is fragile and difficult to treat as a clean upstream integration.

I would like to see an official way for hook scripts to receive stable bundle/plugin context, for example:

• plugin-provided hooks as a first-class capability
• or command hooks that can be explicitly associated with a plugin/bundle
• and, when that association exists, hook execution should expose context such as:
  • pluginId
  • pluginName
  • pluginRoot
  • and/or environment variables that carry the same information

This would let reusable hook scripts read their own bundled assets safely, without depending on local installation layout.

Additional information

I traced the current codex-rs implementation before filing this.

What already exists:

• the plugin system already has a strong internal notion of plugin root
  • LoadedPlugin.root
  • PluginStore.active_plugin_root(...)
  • manifest resolution through .codex-plugin/plugin.json
• Codex already carries plugin provenance in other areas, such as MCP/tool metadata

What seems missing:

• hooks are still discovered only from config layers (System, User, Project) via hooks.json
• hook input exposes session/repo context like cwd, session_id, model, permission_mode, and source
• hook execution does not expose bundle/plugin context to the script

So the gap appears to be:

• plugins know their root
• hooks know their hooks.json source path
• but hook scripts do not know whether they are associated with a bundle/plugin, or where that bundle/plugin lives on disk

One implementation direction that seems consistent with the current architecture:

1. Add first-class plugin-provided hooks, or add optional plugin association to command hook handlers
2. Resolve plugin identity/root in codex-core using the existing plugin store / manifest logic
3. Pass the resolved bundle/plugin context into hook execution through stdin JSON, environment variables, or both

Why this would help:

• avoids hardcoded install paths
• avoids fragile path inference in hook scripts
• makes reusable hook integrations much easier to ship cleanly
• aligns hooks with existing plugin concepts already present elsewhere in Codex