SpyBara
Go Premium Account
2026
26 Mar 2026, 18:27
14 May 2026, 21:00 14 May 2026, 07:00 13 May 2026, 00:57 12 May 2026, 01:59 11 May 2026, 18:00 7 May 2026, 20:02 7 May 2026, 17:08 5 May 2026, 23:00 2 May 2026, 06:45 2 May 2026, 00:48 1 May 2026, 18:29 30 Apr 2026, 18:36 29 Apr 2026, 12:40 29 Apr 2026, 00:50 25 Apr 2026, 06:37 25 Apr 2026, 00:42 24 Apr 2026, 18:20 24 Apr 2026, 12:28 23 Apr 2026, 18:31 23 Apr 2026, 12:28 23 Apr 2026, 00:46 22 Apr 2026, 18:29 22 Apr 2026, 00:42 21 Apr 2026, 18:29 21 Apr 2026, 12:30 21 Apr 2026, 06:45 20 Apr 2026, 18:26 20 Apr 2026, 06:53 18 Apr 2026, 18:18 17 Apr 2026, 00:44 16 Apr 2026, 18:31 16 Apr 2026, 00:46 15 Apr 2026, 18:31 15 Apr 2026, 06:44 14 Apr 2026, 18:31 14 Apr 2026, 12:29 13 Apr 2026, 18:37 13 Apr 2026, 00:44 12 Apr 2026, 06:38 10 Apr 2026, 18:23 9 Apr 2026, 00:33 8 Apr 2026, 18:32 8 Apr 2026, 00:40 7 Apr 2026, 00:40 2 Apr 2026, 18:23 31 Mar 2026, 06:35 31 Mar 2026, 00:39 28 Mar 2026, 06:26 28 Mar 2026, 00:36 27 Mar 2026, 18:23 27 Mar 2026, 00:39 26 Mar 2026, 18:27 25 Mar 2026, 18:24 23 Mar 2026, 18:22 20 Mar 2026, 00:35 18 Mar 2026, 12:23 18 Mar 2026, 00:36 17 Mar 2026, 18:24 17 Mar 2026, 00:33 16 Mar 2026, 18:25 16 Mar 2026, 12:23 14 Mar 2026, 00:32 13 Mar 2026, 18:15 13 Mar 2026, 00:34 11 Mar 2026, 00:31 9 Mar 2026, 00:34 8 Mar 2026, 18:10 8 Mar 2026, 00:35 7 Mar 2026, 18:10 7 Mar 2026, 06:14 7 Mar 2026, 00:33 6 Mar 2026, 00:38 5 Mar 2026, 18:41 5 Mar 2026, 06:22 5 Mar 2026, 00:34 4 Mar 2026, 18:18 4 Mar 2026, 06:20 3 Mar 2026, 18:20 3 Mar 2026, 00:35 27 Feb 2026, 18:15 24 Feb 2026, 06:27 24 Feb 2026, 00:33 23 Feb 2026, 18:27 21 Feb 2026, 00:33 20 Feb 2026, 12:16 19 Feb 2026, 20:53 19 Feb 2026, 20:37
27 Mar 2026, 00:39
14 May 2026, 21:00 14 May 2026, 07:00 13 May 2026, 00:57 12 May 2026, 01:59 11 May 2026, 18:00 7 May 2026, 20:02 7 May 2026, 17:08 5 May 2026, 23:00 2 May 2026, 06:45 2 May 2026, 00:48 1 May 2026, 18:29 30 Apr 2026, 18:36 29 Apr 2026, 12:40 29 Apr 2026, 00:50 25 Apr 2026, 06:37 25 Apr 2026, 00:42 24 Apr 2026, 18:20 24 Apr 2026, 12:28 23 Apr 2026, 18:31 23 Apr 2026, 12:28 23 Apr 2026, 00:46 22 Apr 2026, 18:29 22 Apr 2026, 00:42 21 Apr 2026, 18:29 21 Apr 2026, 12:30 21 Apr 2026, 06:45 20 Apr 2026, 18:26 20 Apr 2026, 06:53 18 Apr 2026, 18:18 17 Apr 2026, 00:44 16 Apr 2026, 18:31 16 Apr 2026, 00:46 15 Apr 2026, 18:31 15 Apr 2026, 06:44 14 Apr 2026, 18:31 14 Apr 2026, 12:29 13 Apr 2026, 18:37 13 Apr 2026, 00:44 12 Apr 2026, 06:38 10 Apr 2026, 18:23 9 Apr 2026, 00:33 8 Apr 2026, 18:32 8 Apr 2026, 00:40 7 Apr 2026, 00:40 2 Apr 2026, 18:23 31 Mar 2026, 06:35 31 Mar 2026, 00:39 28 Mar 2026, 06:26 28 Mar 2026, 00:36 27 Mar 2026, 18:23 27 Mar 2026, 00:39 26 Mar 2026, 18:27 25 Mar 2026, 18:24 23 Mar 2026, 18:22 20 Mar 2026, 00:35 18 Mar 2026, 12:23 18 Mar 2026, 00:36 17 Mar 2026, 18:24 17 Mar 2026, 00:33 16 Mar 2026, 18:25 16 Mar 2026, 12:23 14 Mar 2026, 00:32 13 Mar 2026, 18:15 13 Mar 2026, 00:34 11 Mar 2026, 00:31 9 Mar 2026, 00:34 8 Mar 2026, 18:10 8 Mar 2026, 00:35 7 Mar 2026, 18:10 7 Mar 2026, 06:14 7 Mar 2026, 00:33 6 Mar 2026, 00:38 5 Mar 2026, 18:41 5 Mar 2026, 06:22 5 Mar 2026, 00:34 4 Mar 2026, 18:18 4 Mar 2026, 06:20 3 Mar 2026, 18:20 3 Mar 2026, 00:35 27 Feb 2026, 18:15 24 Feb 2026, 06:27 24 Feb 2026, 00:33 23 Feb 2026, 18:27 21 Feb 2026, 00:33 20 Feb 2026, 12:16 19 Feb 2026, 20:53 19 Feb 2026, 20:37
Tue 3 00:35 Tue 3 18:20 Wed 4 06:20 Wed 4 18:18 Thu 5 00:34 Thu 5 06:22 Thu 5 18:41 Fri 6 00:38 Sat 7 00:33 Sat 7 06:14 Sat 7 18:10 Sun 8 00:35 Sun 8 18:10 Mon 9 00:34 Wed 11 00:31 Fri 13 00:34 Fri 13 18:15 Sat 14 00:32 Mon 16 12:23 Mon 16 18:25 Tue 17 00:33 Tue 17 18:24 Wed 18 00:36 Wed 18 12:23 Fri 20 00:35 Mon 23 18:22 Wed 25 18:24 Thu 26 18:27 Fri 27 00:39 Fri 27 18:23 Sat 28 00:36 Sat 28 06:26 Tue 31 00:39 Tue 31 06:35
Details

54Skills are often the best fit for reusable workflows because they support richer instructions, scripts, and references while staying reusable across tasks.54Skills are often the best fit for reusable workflows because they support richer instructions, scripts, and references while staying reusable across tasks.

55Skills are loaded and visible to the agent (at least their metadata), so Codex can discover and choose them implicitly. This keeps rich workflows available without bloating context up front.55Skills are loaded and visible to the agent (at least their metadata), so Codex can discover and choose them implicitly. This keeps rich workflows available without bloating context up front.

56 56 

57Use skill folders to author and iterate on workflows locally. If a plugin

58already exists for the workflow, install it first to reuse a proven setup. When

59you want to distribute your own workflow across teams or bundle it with app

60integrations, package it as [plugins](https://developers.openai.com/codex/plugins). Skills remain the

61authoring format; plugins are the installable distribution unit.

62 

57A skill is typically a `SKILL.md` file plus optional scripts, references, and assets.63A skill is typically a `SKILL.md` file plus optional scripts, references, and assets.

58 64 

59- my-skill/65- my-skill/


87 93 

88Skills can be global (in your user directory, for you as a developer) or repo-specific (checked into `.agents/skills`, for your team). Put repo skills in `.agents/skills` when the workflow applies to that project; use your user directory for skills you want across all repos.94Skills can be global (in your user directory, for you as a developer) or repo-specific (checked into `.agents/skills`, for your team). Put repo skills in `.agents/skills` when the workflow applies to that project; use your user directory for skills you want across all repos.

89 95 

90| Layer | Global | repo |96| Layer | Global | Repo |

91| :----- | :--------------------- | :--------------------------------------------- |97| :----- | :--------------------- | :--------------------------------------------- |

92| AGENTS | `~/.codex/AGENTS.md` | `AGENTS.md` in repo root or nested directories |98| AGENTS | `~/.codex/AGENTS.md` | `AGENTS.md` in repo root or nested directories |

93| Skills | `$HOME/.agents/skills` | `.agents/skills` in repo |99| Skills | `$HOME/.agents/skills` | `.agents/skills` in repo |


145Build in this order:151Build in this order:

146 152 

1471. [Custom instructions with AGENTS.md](https://developers.openai.com/codex/guides/agents-md) so Codex follows your repo conventions. Add pre-commit hooks and linters to enforce those rules.1531. [Custom instructions with AGENTS.md](https://developers.openai.com/codex/guides/agents-md) so Codex follows your repo conventions. Add pre-commit hooks and linters to enforce those rules.

1482. [Skills](https://developers.openai.com/codex/skills) so you never have the same conversation twice. Skills can include a `scripts/` directory with CLI scripts or pair with [MCP](https://developers.openai.com/codex/mcp) for external systems.1542. Install a [plugin](https://developers.openai.com/codex/plugins) when a reusable workflow already exists. Otherwise, create a [skill](https://developers.openai.com/codex/skills) and package it as a plugin when you want to share it.

1493. [MCP](https://developers.openai.com/codex/mcp) when workflows need external systems (Linear, GitHub, docs servers, design tools).1553. [MCP](https://developers.openai.com/codex/mcp) when workflows need external systems (Linear, GitHub, docs servers, design tools).

1504. [Subagents](https://developers.openai.com/codex/subagents) when you're ready to delegate noisy or specialized tasks to subagents.1564. [Subagents](https://developers.openai.com/codex/subagents) when you're ready to delegate noisy or specialized tasks to subagents.

Details

88 88 

89Relative paths inside a project config (for example, `model_instructions_file`) are resolved relative to the `.codex/` folder that contains the `config.toml`.89Relative paths inside a project config (for example, `model_instructions_file`) are resolved relative to the `.codex/` folder that contains the `config.toml`.

90 90 

91## Hooks (experimental)

92 

93Codex can also load lifecycle hooks from `hooks.json` files that sit next to

94active config layers.

95 

96In practice, the two most useful locations are:

97 

98- `~/.codex/hooks.json`

99- `<repo>/.codex/hooks.json`

100 

101Turn hooks on with:

102 

103```toml

104[features]

105codex_hooks = true

106```

107 

108For the current event list, input fields, output behavior, and limitations, see

109[Hooks](https://developers.openai.com/codex/hooks).

110 

91## Agent roles (`[agents]` in `config.toml`)111## Agent roles (`[agents]` in `config.toml`)

92 112 

93For subagent role configuration (`[agents]` in `config.toml`), see [Subagents](https://developers.openai.com/codex/subagents).113For subagent role configuration (`[agents]` in `config.toml`), see [Subagents](https://developers.openai.com/codex/subagents).

config-basic.md +3 −0

Details

148| Key | Default | Maturity | Description |148| Key | Default | Maturity | Description |

149| -------------------- | :-------------------: | ------------ | ---------------------------------------------------------------------------------------- |149| -------------------- | :-------------------: | ------------ | ---------------------------------------------------------------------------------------- |

150| `apps` | false | Experimental | Enable ChatGPT Apps/connectors support |150| `apps` | false | Experimental | Enable ChatGPT Apps/connectors support |

151| `codex_hooks` | false | Under development | Enable lifecycle hooks from `hooks.json`. See [Hooks](https://developers.openai.com/codex/hooks). |

151| `fast_mode` | true | Stable | Enable Fast mode selection and the `service_tier = "fast"` path |152| `fast_mode` | true | Stable | Enable Fast mode selection and the `service_tier = "fast"` path |

152| `multi_agent` | true | Stable | Enable subagent collaboration tools |153| `multi_agent` | true | Stable | Enable subagent collaboration tools |

153| `personality` | true | Stable | Enable personality selection controls |154| `personality` | true | Stable | Enable personality selection controls |


166 167 

167Omit feature keys to keep their defaults.168Omit feature keys to keep their defaults.

168 169 

170For the current lifecycle hooks MVP, see [Hooks](https://developers.openai.com/codex/hooks).

171 

169### Enabling features172### Enabling features

170 173 

171- In `config.toml`, add `feature_name = true` under `[features]`.174- In `config.toml`, add `feature_name = true` under `[features]`.

Details

46| `experimental_compact_prompt_file` | `string (path)` | Load the compaction prompt override from a file (experimental). |46| `experimental_compact_prompt_file` | `string (path)` | Load the compaction prompt override from a file (experimental). |

47| `experimental_use_unified_exec_tool` | `boolean` | Legacy name for enabling unified exec; prefer `[features].unified_exec` or `codex --enable unified_exec`. |47| `experimental_use_unified_exec_tool` | `boolean` | Legacy name for enabling unified exec; prefer `[features].unified_exec` or `codex --enable unified_exec`. |

48| `features.apps` | `boolean` | Enable ChatGPT Apps/connectors support (experimental). |48| `features.apps` | `boolean` | Enable ChatGPT Apps/connectors support (experimental). |

49| `features.codex_hooks` | `boolean` | Enable lifecycle hooks loaded from `hooks.json` (under development; off by default). |

49| `features.enable_request_compression` | `boolean` | Compress streaming request bodies with zstd when supported (stable; on by default). |50| `features.enable_request_compression` | `boolean` | Compress streaming request bodies with zstd when supported (stable; on by default). |

50| `features.fast_mode` | `boolean` | Enable Fast mode selection and the `service_tier = "fast"` path (stable; on by default). |51| `features.fast_mode` | `boolean` | Enable Fast mode selection and the `service_tier = "fast"` path (stable; on by default). |

51| `features.multi_agent` | `boolean` | Enable multi-agent collaboration tools (`spawn_agent`, `send_input`, `resume_agent`, `wait_agent`, and `close_agent`) (stable; on by default). |52| `features.multi_agent` | `boolean` | Enable multi-agent collaboration tools (`spawn_agent`, `send_input`, `resume_agent`, `wait_agent`, and `close_agent`) (stable; on by default). |


645 646 

646Key647Key

647 648 

649`features.codex_hooks`

650 

651Type / Values

652 

653`boolean`

654 

655Details

656 

657Enable lifecycle hooks loaded from `hooks.json` (under development; off by default).

658 

659Key

660 

648`features.enable_request_compression`661`features.enable_request_compression`

649 662 

650Type / Values663Type / Values

Details

360# Leave this table empty to accept defaults. Set explicit booleans to opt in/out.360# Leave this table empty to accept defaults. Set explicit booleans to opt in/out.

361# shell_tool = true361# shell_tool = true

362# apps = false362# apps = false

363# codex_hooks = false

363# unified_exec = true364# unified_exec = true

364# shell_snapshot = true365# shell_snapshot = true

365# multi_agent = true366# multi_agent = true

hooks.md +398 −0 added

Details

1# Hooks

2 

3Experimental. Hooks are under active development. Windows support temporarily

4disabled.

5 

6Hooks are an extensibility framework for Codex. They allow

7you to inject your own scripts into the agentic loop, enabling features such as:

8 

9- Send the conversation to a custom logging/analytics engine

10- Scan your team's prompts to block accidentally pasting API keys

11- Summarize conversations to create persistent memories automatically

12- Run a custom validator when a conversation turn stops, enforcing standards

13- Customize prompting when in a certain directory

14 

15Hooks are behind a feature flag in `config.toml`:

16 

17```toml

18[features]

19codex_hooks = true

20```

21 

22Runtime behavior to keep in mind:

23 

24- Matching hooks from multiple files all run.

25- Multiple matching command hooks for the same event are launched concurrently,

26 so one hook cannot prevent another matching hook from starting.

27- `PreToolUse`, `PostToolUse`, `UserPromptSubmit`, and `Stop` run at turn

28 scope.

29- Hooks are currently disabled on Windows.

30 

31## Where Codex looks for hooks

32 

33Codex discovers `hooks.json` next to active config layers.

34 

35In practice, the two most useful locations are:

36 

37- `~/.codex/hooks.json`

38- `<repo>/.codex/hooks.json`

39 

40If more than one `hooks.json` file exists, Codex loads all matching hooks.

41Higher-precedence config layers do not replace lower-precedence hooks.

42 

43## Config shape

44 

45Hooks are organized in three levels:

46 

47- A hook event such as `PreToolUse`, `PostToolUse`, or `Stop`

48- A matcher group that decides when that event matches

49- One or more hook handlers that run when the matcher group matches

50 

51```json

52{

53 "hooks": {

54 "SessionStart": [

55 {

56 "matcher": "startup|resume",

57 "hooks": [

58 {

59 "type": "command",

60 "command": "python3 ~/.codex/hooks/session_start.py",

61 "statusMessage": "Loading session notes"

62 }

63 ]

64 }

65 ],

66 "PreToolUse": [

67 {

68 "matcher": "Bash",

69 "hooks": [

70 {

71 "type": "command",

72 "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py\"",

73 "statusMessage": "Checking Bash command"

74 }

75 ]

76 }

77 ],

78 "PostToolUse": [

79 {

80 "matcher": "Bash",

81 "hooks": [

82 {

83 "type": "command",

84 "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/post_tool_use_review.py\"",

85 "statusMessage": "Reviewing Bash output"

86 }

87 ]

88 }

89 ],

90 "UserPromptSubmit": [

91 {

92 "hooks": [

93 {

94 "type": "command",

95 "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/user_prompt_submit_data_flywheel.py\""

96 }

97 ]

98 }

99 ],

100 "Stop": [

101 {

102 "hooks": [

103 {

104 "type": "command",

105 "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/stop_continue.py\"",

106 "timeout": 30

107 }

108 ]

109 }

110 ]

111 }

112}

113```

114 

115Notes:

116 

117- `timeout` is in seconds.

118- `timeoutSec` is also accepted as an alias.

119- If `timeout` is omitted, Codex uses `600` seconds.

120- `statusMessage` is optional.

121- Commands run with the session `cwd` as their working directory.

122- For repo-local hooks, prefer resolving from the git root instead of using a

123 relative path such as `.codex/hooks/...`. Codex may be started from a

124 subdirectory, and a git-root-based path keeps the hook location stable.

125 

126## Matcher patterns

127 

128The `matcher` field is a regex string that filters when hooks fire. Use `"*"`,

129`""`, or omit `matcher` entirely to match every occurrence of a supported

130event.

131 

132Only some current Codex events honor `matcher`:

133 

134| Event | What `matcher` filters | Notes |

135| --- | --- | --- |

136| `PostToolUse` | tool name | Current Codex runtime only emits `Bash`. |

137| `PreToolUse` | tool name | Current Codex runtime only emits `Bash`. |

138| `SessionStart` | start source | Current runtime values are `startup` and `resume`. |

139| `UserPromptSubmit` | not supported | Any configured `matcher` is ignored for this event. |

140| `Stop` | not supported | Any configured `matcher` is ignored for this event. |

141 

142Examples:

143 

144- `Bash`

145- `startup|resume`

146- `Edit|Write`

147 

148That last example is still a valid regex, but current Codex `PreToolUse` and

149`PostToolUse` events only emit `Bash`, so it will not match anything today.

150 

151## Common input fields

152 

153Every command hook receives one JSON object on `stdin`.

154 

155These are the shared fields you will usually use:

156 

157| Field | Type | Meaning |

158| --- | --- | --- |

159| `session_id` | `string` | Current session or thread id. |

160| `transcript_path` | `string | null` | Path to the session transcript file, if any |

161| `cwd` | `string` | Working directory for the session |

162| `hook_event_name` | `string` | Current hook event name |

163| `model` | `string` | Active model slug |

164 

165Turn-scoped hooks list `turn_id` in their event-specific tables.

166 

167If you need the full wire format, see [Schemas](#schemas).

168 

169## Common output fields

170 

171`SessionStart`, `UserPromptSubmit`, and `Stop` support these shared JSON

172fields:

173 

174```json

175{

176 "continue": true,

177 "stopReason": "optional",

178 "systemMessage": "optional",

179 "suppressOutput": false

180}

181```

182 

183| Field | Effect |

184| ---------------- | ----------------------------------------------- |

185| `continue` | If `false`, marks that hook run as stopped |

186| `stopReason` | Recorded as the reason for stopping |

187| `systemMessage` | Surfaced as a warning in the UI or event stream |

188| `suppressOutput` | Parsed today but not yet implemented |

189 

190Exit `0` with no output is treated as success and Codex continues.

191 

192`PreToolUse` supports `systemMessage`, but `continue`, `stopReason`, and

193`suppressOutput` are not currently supported for that event.

194 

195`PostToolUse` supports `systemMessage`, `continue: false`, and `stopReason`.

196`suppressOutput` is parsed but not currently supported for that event.

197 

198## Hooks

199 

200### SessionStart

201 

202`matcher` is applied to `source` for this event.

203 

204Fields in addition to [Common input fields](#common-input-fields):

205 

206| Field | Type | Meaning |

207| --- | --- | --- |

208| `source` | `string` | How the session started: `startup` or `resume` |

209 

210Plain text on `stdout` is added as extra developer context.

211 

212JSON on `stdout` supports [Common output fields](#common-output-fields) and this

213hook-specific shape:

214 

215```json

216{

217 "hookSpecificOutput": {

218 "hookEventName": "SessionStart",

219 "additionalContext": "Load the workspace conventions before editing."

220 }

221}

222```

223 

224That `additionalContext` text is added as extra developer context.

225 

226### PreToolUse

227 

228Currently `PreToolUse` only supports Bash tool interception. The model can

229still work around this by writing its own script to disk and then running that

230script with Bash, so treat this as a useful guardrail rather than a complete

231enforcement boundary.

232 

233`matcher` is applied to `tool_name`, which currently always equals `Bash`.

234 

235Fields in addition to [Common input fields](#common-input-fields):

236 

237| Field | Type | Meaning |

238| --- | --- | --- |

239| `turn_id` | `string` | Codex-specific extension. Active Codex turn id |

240| `tool_name` | `string` | Currently always `Bash` |

241| `tool_use_id` | `string` | Tool-call id for this invocation |

242| `tool_input.command` | `string` | Shell command Codex is about to run |

243 

244Plain text on `stdout` is ignored.

245 

246JSON on `stdout` can use `systemMessage` and can block a Bash command with this

247hook-specific shape:

248 

249```json

250{

251 "hookSpecificOutput": {

252 "hookEventName": "PreToolUse",

253 "permissionDecision": "deny",

254 "permissionDecisionReason": "Destructive command blocked by hook."

255 }

256}

257```

258 

259Codex also accepts this older block shape:

260 

261```json

262{

263 "decision": "block",

264 "reason": "Destructive command blocked by hook."

265}

266```

267 

268You can also use exit code `2` and write the blocking reason to `stderr`.

269 

270`permissionDecision: "allow"` and `"ask"`, legacy `decision: "approve"`,

271`updatedInput`, `additionalContext`, `continue: false`, `stopReason`, and

272`suppressOutput` are parsed but not supported yet, so they fail open.

273 

274### PostToolUse

275 

276Currently `PostToolUse` only supports Bash tool results. It is not limited to

277commands that exit successfully: non-interactive `exec_command` calls can still

278trigger `PostToolUse` when Codex emits a Bash post-tool payload. It cannot undo

279side effects from the command that already ran.

280 

281`matcher` is applied to `tool_name`, which currently always equals `Bash`.

282 

283Fields in addition to [Common input fields](#common-input-fields):

284 

285| Field | Type | Meaning |

286| --- | --- | --- |

287| `turn_id` | `string` | Codex-specific extension. Active Codex turn id |

288| `tool_name` | `string` | Currently always `Bash` |

289| `tool_use_id` | `string` | Tool-call id for this invocation |

290| `tool_input.command` | `string` | Shell command Codex just ran |

291| `tool_response` | `JSON value` | Bash tool output payload. Today this is usually a JSON string |

292 

293Plain text on `stdout` is ignored.

294 

295JSON on `stdout` can use `systemMessage` and this hook-specific shape:

296 

297```json

298{

299 "decision": "block",

300 "reason": "The Bash output needs review before continuing.",

301 "hookSpecificOutput": {

302 "hookEventName": "PostToolUse",

303 "additionalContext": "The command updated generated files."

304 }

305}

306```

307 

308That `additionalContext` text is added as extra developer context.

309 

310For this event, `decision: "block"` does not undo the completed Bash command.

311Instead, Codex records the feedback, replaces the tool result with that

312feedback, and continues the model from the hook-provided message.

313 

314You can also use exit code `2` and write the feedback reason to `stderr`.

315 

316To stop normal processing of the original tool result after the command has

317already run, return `continue: false`. Codex will replace the tool result with

318your feedback or stop text and continue from there.

319 

320`updatedMCPToolOutput` and `suppressOutput` are parsed but not supported yet,

321so they fail open.

322 

323### UserPromptSubmit

324 

325`matcher` is not currently used for this event.

326 

327Fields in addition to [Common input fields](#common-input-fields):

328 

329| Field | Type | Meaning |

330| --- | --- | --- |

331| `turn_id` | `string` | Codex-specific extension. Active Codex turn id |

332| `prompt` | `string` | User prompt that is about to be sent |

333 

334Plain text on `stdout` is added as extra developer context.

335 

336JSON on `stdout` supports [Common output fields](#common-output-fields) and

337this hook-specific shape:

338 

339```json

340{

341 "hookSpecificOutput": {

342 "hookEventName": "UserPromptSubmit",

343 "additionalContext": "Ask for a clearer reproduction before editing files."

344 }

345}

346```

347 

348That `additionalContext` text is added as extra developer context.

349 

350To block the prompt, return:

351 

352```json

353{

354 "decision": "block",

355 "reason": "Ask for confirmation before doing that."

356}

357```

358 

359You can also use exit code `2` and write the blocking reason to `stderr`.

360 

361### Stop

362 

363`matcher` is not currently used for this event.

364 

365Fields in addition to [Common input fields](#common-input-fields):

366 

367| Field | Type | Meaning |

368| --- | --- | --- |

369| `turn_id` | `string` | Codex-specific extension. Active Codex turn id |

370| `stop_hook_active` | `boolean` | Whether this turn was already continued by `Stop` |

371| `last_assistant_message` | `string | null` | Latest assistant message text, if available |

372 

373`Stop` expects JSON on `stdout` when it exits `0`. Plain text output is invalid

374for this event.

375 

376JSON on `stdout` supports [Common output fields](#common-output-fields). To keep

377Codex going, return:

378 

379```json

380{

381 "decision": "block",

382 "reason": "Run one more pass over the failing tests."

383}

384```

385 

386You can also use exit code `2` and write the continuation reason to `stderr`.

387 

388For this event, `decision: "block"` does not reject the turn. Instead, it tells

389Codex to continue and automatically creates a new continuation prompt that acts

390as a new user prompt, using your `reason` as that prompt text.

391 

392If any matching `Stop` hook returns `continue: false`, that takes precedence

393over continuation decisions from other matching `Stop` hooks.

394 

395## Schemas

396 

397If you need the exact current wire format, see the generated schemas in the

398[Codex GitHub repository](https://github.com/openai/codex/tree/main/codex-rs/hooks/schema/generated).

Details

161- Telemetry or incident summaries161- Telemetry or incident summaries

162- Standard debugging flows162- Standard debugging flows

163 163 

164The `$skill-creator` skill is the best place to start to scaffold the first version of a skill and to use the `$skill-installer` skill to install it locally. One of the most important parts of a skill is the description. It should say what the skill does and when to use it.164The `$skill-creator` skill is the best place to start to scaffold the first version of a skill. Keep the first version local while you iterate. When it’s ready to share broadly, package it as a [plugin](https://developers.openai.com/codex/plugins). One of the most important parts of a skill is the description. It should say what the skill does and when to use it.

165 165 

166Personal skills are stored in `$HOME/.agents/skills`, and shared team skills166Personal skills are stored in `$HOME/.agents/skills`, and shared team skills

167 can be checked into `.agents/skills` inside a repository. This is especially167 can be checked into `.agents/skills` inside a repository. This is especially

plugins.md +378 −0 added

Details

1# Plugins

2 

3## What plugins are

4 

5Plugins are installable bundles for reusable Codex workflows. They make it

6easier to share the same setup across projects or teams, and they can package

7skills, optional app integrations, and MCP server configurations in a single

8place.

9 

10A plugin can contain:

11 

12- **Skills:** prompts that describe workflows to Codex and can be

13 progressively discovered by the agent.

14- **Apps:** optional app integrations or connector mappings packaged with the

15 plugin.

16- **MCP servers:** remote tools or shared context the plugin needs.

17 

18More plugin components are coming soon.

19 

20## Use and install plugins

21 

22### In the Codex app

23 

24Plugins curated by OpenAI appear in the Codex directory. Start there when you

25want ready-made workflows or app integrations.

26 

27![Codex plugin directory](/images/codex/plugins/directory.png)

28 

29### In the CLI

30 

31In Codex CLI, run the following command to open the plugins surface:

32 

33```text

34codex

35/plugins

36```

37 

38![Plugin directory in Codex CLI](/images/codex/plugins/cli_light.png)

39 

40### Use plugins locally

41 

42For the fastest setup, use the built-in `@plugin-creator` skill to scaffold a

43local plugin.

44 

45![plugin-creator skill in Codex](/images/codex/plugins/plugin-creator.png)

46 

47It creates the required `.codex-plugin/plugin.json` manifest and

48can also generate a local marketplace entry for testing.

49 

50If you already have a plugin from another ecosystem or a plugin you built

51yourself, you can add it to your local marketplace with `@plugin-creator`.

52 

53![how to invoke the plugin-creator skill](/images/codex/plugins/plugin-creator-invoke.png)

54 

55In the plugin directory, you can also load your own local marketplace with a

56custom marketplace name and browse the plugins there.

57 

58![custom local marketplace in the plugin directory](/images/codex/plugins/codex-local-plugin-light.png)

59 

60#### Install a local plugin manually

61 

62Use a repo marketplace or a personal marketplace, depending on who should be

63able to access the plugin.

64 

65Add a marketplace file at `$REPO_ROOT/.agents/plugins/marketplace.json`

66and store your plugins under `$REPO_ROOT/plugins/`.

67 

68**Repo marketplace example**

69 

70Step 1: Copy the plugin folder into `$REPO_ROOT/plugins/my-plugin`.

71 

72```

73mkdir -p ./plugins

74cp -R /absolute/path/to/my-plugin ./plugins/my-plugin

75```

76 

77Step 2: Add or update `$REPO_ROOT/.agents/plugins/marketplace.json` so

78that `source.path` points to that plugin directory with a `./`-prefixed

79relative path:

80 

81```

82{

83 "name": "local-repo",

84 "plugins": [

85 {

86 "name": "my-plugin",

87 "source": {

88 "source": "local",

89 "path": "./plugins/my-plugin"

90 },

91 "policy": {

92 "installation": "AVAILABLE",

93 "authentication": "ON_INSTALL"

94 },

95 "category": "Productivity"

96 }

97 ]

98}

99```

100 

101Step 3: Restart Codex and verify that the plugin appears.

102 

103Add a marketplace file at `~/.agents/plugins/marketplace.json` and store

104your plugins under `~/.codex/plugins/`.

105 

106**Personal marketplace example**

107 

108Step 1: Copy the plugin folder into `~/.codex/plugins/my-plugin`.

109 

110```

111mkdir -p ~/.codex/plugins

112cp -R /absolute/path/to/my-plugin ~/.codex/plugins/my-plugin

113```

114 

115Step 2: Add or update `~/.agents/plugins/marketplace.json` so that the

116plugin entry’s `source.path` points to that directory.

117 

118Step 3: Restart Codex and verify that the plugin appears.

119 

120The marketplace file points to the plugin location, so those directories are

121examples rather than fixed requirements. Codex resolves `source.path` relative

122to the marketplace root, not relative to the `.agents/plugins/` folder. See

123[Marketplace metadata](#marketplace-metadata) for the file format.

124 

125After you change the plugin, update the plugin directory that your marketplace

126entry points to and restart Codex so the local install picks up the new files.

127 

128### Marketplace metadata

129 

130If you maintain a repo marketplace, define it in

131`$REPO_ROOT/.agents/plugins/marketplace.json`. For a personal marketplace, use

132`~/.agents/plugins/marketplace.json`. A marketplace file controls plugin

133ordering and install policies in Codex-facing catalogs. Before you add a plugin

134to a marketplace, make sure its `version`, publisher metadata, and

135install-surface copy are ready for other developers to see.

136 

137```

138{

139 "name": "openai-curated",

140 "interface": {

141 "displayName": "ChatGPT Official"

142 },

143 "plugins": [

144 {

145 "name": "my-plugin",

146 "source": {

147 "source": "local",

148 "path": "./plugins/my-plugin"

149 },

150 "policy": {

151 "installation": "AVAILABLE",

152 "authentication": "ON_INSTALL"

153 },

154 "category": "Productivity"

155 }

156 ]

157}

158```

159 

160- Use top-level `name` to identify the marketplace.

161- Use `interface.displayName` for the marketplace title shown in Codex.

162- Point each plugin entry’s `source.path` at the plugin directory you want

163 Codex to load. For repo installs, that often lives under

164 `./plugins/`. For personal installs, it often lives under

165 `~/.codex/plugins/`.

166- Keep `source.path` relative to the marketplace root, start it with `./`, and

167 keep it inside that root.

168- Always include `policy.installation`, `policy.authentication`, and

169 `category` on each plugin entry.

170- Use `policy.installation` values such as `AVAILABLE`,

171 `INSTALLED_BY_DEFAULT`, or `NOT_AVAILABLE`.

172- Use `policy.authentication` to decide whether auth happens on install or

173 first use.

174 

175The marketplace controls where Codex loads the plugin from. `source.path` can

176point somewhere else if your plugin lives outside those example directories. A

177marketplace file can live in the repo where you are developing the plugin or in

178a separate marketplace repo, and one marketplace file can point to one plugin

179or many.

180 

181### How Codex uses marketplaces

182 

183A plugin marketplace is a JSON catalog of plugins that Codex can read and

184install.

185 

186Codex can read marketplace files from:

187 

188- the curated marketplace that powers the official Plugin Directory

189- a repo marketplace at `$REPO_ROOT/.agents/plugins/marketplace.json`

190- a personal marketplace at `~/.agents/plugins/marketplace.json`

191 

192You can install any plugin exposed through a marketplace. Codex installs

193plugins into

194`~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/`. For local

195plugins, `$VERSION` is `local`, and Codex loads the installed copy from that

196cache path rather than directly from the marketplace entry.

197 

198You can enable or disable each plugin individually. Codex stores each plugin’s

199on or off state in `~/.codex/config.toml`.

200 

201## Build and distribute plugins

202 

203### When to create a plugin

204 

205Use local skills when:

206 

207- You are iterating on one repo or one workflow.

208- The behavior is personal or project-specific.

209- You are experimenting before you package something reusable.

210 

211Use plugins when:

212 

213- You want the same skills or app integrations available across teams or

214 projects.

215- You want to bundle skills, MCP config, and app integrations into one

216 installable unit.

217- You want a stable, versioned package for teammates or a marketplace.

218 

219Start local, then package the workflow as a plugin when you are ready to share

220it.

221 

222### Plugin structure

223 

224Every plugin has a manifest at `.codex-plugin/plugin.json`. It can also include

225a `skills/` directory, an `.app.json` file that points at one or more apps or

226connectors, and assets used to present the plugin across supported surfaces.

227 

228- my-plugin/

229 

230 - .codex-plugin/

231 

232 - plugin.json Required: plugin manifest

233 - skills/

234 

235 - my-skill/

236 

237 - SKILL.md Optional: skill instructions

238 - .app.json Optional: app or connector mappings

239 - .mcp.json Optional: MCP server configuration

240 - assets/ Optional: icons, logos, screenshots

241 

242Only `plugin.json` belongs in `.codex-plugin/`. Keep `skills/`, `assets/`,

243`.mcp.json`, and `.app.json` at the plugin root.

244 

245Published plugins typically use a richer manifest than the minimal example that

246appears in quick-start scaffolds. The manifest has three jobs:

247 

248- Identify the plugin.

249- Point to bundled components such as skills, apps, or MCP servers.

250- Provide install-surface metadata such as descriptions, icons, and legal links.

251 

252Here’s a complete manifest example:

253 

254```

255{

256 "name": "my-plugin",

257 "version": "0.1.0",

258 "description": "Bundle reusable skills and app integrations.",

259 "author": {

260 "name": "Your team",

261 "email": "team@example.com",

262 "url": "https://example.com"

263 },

264 "homepage": "https://example.com/plugins/my-plugin",

265 "repository": "https://github.com/example/my-plugin",

266 "license": "MIT",

267 "keywords": ["research", "crm"],

268 "skills": "./skills/",

269 "mcpServers": "./.mcp.json",

270 "apps": "./.app.json",

271 "interface": {

272 "displayName": "My Plugin",

273 "shortDescription": "Reusable skills and apps",

274 "longDescription": "Distribute skills and app integrations together.",

275 "developerName": "Your team",

276 "category": "Productivity",

277 "capabilities": ["Read", "Write"],

278 "websiteURL": "https://example.com",

279 "privacyPolicyURL": "https://example.com/privacy",

280 "termsOfServiceURL": "https://example.com/terms",

281 "defaultPrompt": [

282 "Use My Plugin to summarize new CRM notes.",

283 "Use My Plugin to triage new customer follow-ups."

284 ],

285 "brandColor": "#10A37F",

286 "composerIcon": "./assets/icon.png",

287 "logo": "./assets/logo.png",

288 "screenshots": ["./assets/screenshot-1.png"]

289 }

290}

291```

292 

293`.codex-plugin/plugin.json` is the required entry point. The other manifest

294fields are optional, but published plugins commonly use them.

295 

296### Create your first plugin

297 

298Start with a minimal plugin that packages one skill.

299 

3001. Create a plugin folder with a manifest at `.codex-plugin/plugin.json`.

301 

302```

303mkdir -p my-first-plugin/.codex-plugin

304```

305 

306`my-first-plugin/.codex-plugin/plugin.json`

307 

308```

309{

310 "name": "my-first-plugin",

311 "version": "1.0.0",

312 "description": "Reusable greeting workflow",

313 "skills": "./skills/"

314}

315```

316 

317Use a stable plugin `name` in kebab-case. Codex uses it as the plugin

318identifier and component namespace.

319 

3202. Add a skill under `skills/<skill-name>/SKILL.md`.

321 

322```

323mkdir -p my-first-plugin/skills/hello

324```

325 

326`my-first-plugin/skills/hello/SKILL.md`

327 

328```

329---

330name: hello

331description: Greet the user with a friendly message.

332---

333 

334Greet the user warmly and ask how you can help.

335```

336 

3373. Follow [Use plugins locally](#use-plugins-locally) to load the plugin in

338 Codex.

339 

340From there, you can add MCP config, app integrations, or marketplace metadata

341as needed.

342 

343### Manifest fields

344 

345Use the top-level fields to define package metadata and point to bundled

346components:

347 

348- `name`, `version`, and `description` identify the plugin.

349- `author`, `homepage`, `repository`, `license`, and `keywords` provide

350 publisher and discovery metadata.

351- `skills`, `mcpServers`, and `apps` point to bundled components relative to

352 the plugin root.

353- `interface` controls how install surfaces present the plugin.

354 

355Use the `interface` object for install-surface metadata:

356 

357- `displayName`, `shortDescription`, and `longDescription` control the title and

358 descriptive copy.

359- `developerName`, `category`, and `capabilities` add publisher and capability

360 metadata.

361- `websiteURL`, `privacyPolicyURL`, and `termsOfServiceURL` provide external

362 links.

363- `defaultPrompt`, `brandColor`, `composerIcon`, `logo`, and `screenshots`

364 control starter prompts and visual presentation.

365 

366### Path rules

367 

368- Keep manifest paths relative to the plugin root and start them with `./`.

369- Store visual assets such as `composerIcon`, `logo`, and `screenshots` under

370 `./assets/` when possible.

371- Use `skills` for bundled skill folders, `apps` for `.app.json`, and

372 `mcpServers` for `.mcp.json`.

373 

374### Publish official public plugins

375 

376Adding plugins to the official Plugin Directory is coming soon.

377 

378Self-serve plugin publishing and management are coming soon.

skills.md +26 −4

Details

1# Agent Skills1# Agent Skills

2 2 

3Use agent skills to extend Codex with task-specific capabilities. A skill packages instructions, resources, and optional scripts so Codex can follow a workflow reliably. You can share skills across teams or with the community. Skills build on the [open agent skills standard](https://agentskills.io).3Use agent skills to extend Codex with task-specific capabilities. A skill packages instructions, resources, and optional scripts so Codex can follow a workflow reliably. Skills build on the [open agent skills standard](https://agentskills.io).

4 

5Skills are the authoring format for reusable workflows. Plugins are the installable distribution unit for reusable skills and apps in Codex. Use skills to design the workflow itself, then package it as a [plugin](https://developers.openai.com/codex/plugins) when you want other developers to install it.

4 6 

5Skills are available in the Codex CLI, IDE extension, and Codex app.7Skills are available in the Codex CLI, IDE extension, and Codex app.

6 8 


65 67 

66Codex supports symlinked skill folders and follows the symlink target when scanning these locations.68Codex supports symlinked skill folders and follows the symlink target when scanning these locations.

67 69 

68## Install skills70These locations are for authoring and local discovery. When you want to

71distribute reusable skills beyond a single repo, or optionally bundle them with

72app integrations, use [plugins](https://developers.openai.com/codex/plugins).

73 

74## Distribute skills with plugins

75 

76Direct skill folders are best for local authoring and repo-scoped workflows. If

77you want to distribute a reusable skill, bundle two or more skills together, or

78ship a skill alongside an app integration, package them as a

79[plugin](https://developers.openai.com/codex/plugins).

69 80 

70To install skills beyond the built-ins, use `$skill-installer`. For example, to install the `$linear` skill:81Plugins can include one or more skills. They can also optionally bundle app

82mappings, MCP server configuration, and presentation assets in a single

83package.

84 

85## Install curated skills for local use

86 

87To add curated skills beyond the built-ins for your own local Codex setup, use `$skill-installer`. For example, to install the `$linear` skill:

71 88 

72```bash89```bash

73$skill-installer linear90$skill-installer linear

74```91```

75 92 

76You can also prompt the installer to download skills from other repositories. Codex detects newly installed skills automatically; if one doesn’t appear, restart Codex.93You can also prompt the installer to download skills from other repositories.

94Codex detects newly installed skills automatically; if one doesn't appear,

95restart Codex.

96 

97Use this for local setup and experimentation. For reusable distribution of your

98own skills, prefer plugins.

77 99 

78## Enable or disable skills100## Enable or disable skills

79 101