You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,17 @@
1
1
# codex-action Changelog
2
2
3
+
## [Unreleased]
4
+
5
+
### Migration notes
6
+
7
+
- This release is additive for `v1.x`: existing workflows that only use `prompt`/`prompt-file` and consume `final-message` continue to work without changes.
8
+
- New observability inputs are optional: `capture-json-events`, `json-events-file`, and `write-step-summary`.
9
+
- New outputs are now available when needed: `structured-output`, `usage-json`, `execution-file`, `session-id`, `conclusion`, `triggered`, and `tracking-comment-id`.
10
+
- Trigger-based execution is opt-in. If you configure any trigger input (`trigger-phrase`, `label-trigger`, or `assignee-trigger`) and no trigger matches, the action exits cleanly with `triggered=false`.
11
+
- Progress comments are opt-in (`track-progress`) and require suitable workflow permissions (for example `issues: write` / `pull-requests: write`).
12
+
-`structured-output` is only populated when `output-schema` (or `output-schema-file`) is used and the final Codex message is valid JSON.
13
+
- No cross-run session resume behavior is introduced in this release (intentional for ephemeral runner compatibility).
| `execution-file` | Path to the raw JSONL event log when `capture-json-events` is enabled. |
161
+
| `session-id` | Session/thread ID extracted from JSON events (diagnostic only). |
162
+
| `conclusion` | Codex run result (`success` or `failure`). |
163
+
| `triggered` | Whether trigger conditions matched and the action proceeded. |
164
+
| `tracking-comment-id`| Comment ID used for progress tracking when `track-progress` is enabled. |
149
165
150
166
As we saw in the example above, we took the `final-message` output of the `run_codex` step and made it an output of the `codex` job in the workflow:
151
167
@@ -185,6 +201,37 @@ jobs:
185
201
full workflow, and [`docs/pass-through-env.md`](./docs/pass-through-env.md) for a
186
202
deeper walkthrough that covers rotation and troubleshooting.
187
203
204
+
### Trigger-driven workflows
205
+
You can gate execution on GitHub event payload data by setting one or more of:
206
+
`trigger-phrase`, `label-trigger`, or `assignee-trigger`.
207
+
208
+
- If no trigger inputs are configured, behavior is unchanged (the action proceeds).
209
+
- If trigger inputs are configured and none match, the action no-ops cleanly with
210
+
output `triggered=false`.
211
+
- If trigger inputs are configured and a match occurs, the action can derive a
212
+
prompt from the event payload when `prompt`/`prompt-file` are not provided.
213
+
214
+
The `sanitize-github-context` input is `true` by default to strip hidden markup
215
+
and zero-width characters before deriving prompt text.
216
+
See [`examples/triggered-progress-review.yml`](./examples/triggered-progress-review.yml)
217
+
for an end-to-end trigger workflow.
218
+
219
+
### JSON event capture and summaries
220
+
Enable `capture-json-events: true` when you want machine-readable execution
221
+
metadata from `codex exec --json`. This powers outputs like `session-id`,
222
+
`usage-json`, and `execution-file`.
223
+
224
+
You can control where the raw JSONL goes with `json-events-file`; otherwise the
225
+
action writes to a temporary file and exposes its path via `execution-file`.
226
+
227
+
`write-step-summary`defaults to `true` and appends run metadata plus a concise
228
+
final-message preview to the GitHub Step Summary.
229
+
230
+
### Progress comments
231
+
Set `track-progress: true` on issue/PR events to create/update a progress comment
232
+
while Codex runs. Add `use-sticky-comment: true` to reuse one marker-based comment
233
+
across runs and reduce comment noise.
234
+
188
235
- Run this action after `actions/checkout@v5` so Codex has access to your repository contents.
189
236
- To use a non-default Responses endpoint (for example Azure OpenAI), set `responses-api-endpoint` to the provider's URL while keeping `openai-api-key` populated; the proxy will still send `Authorization: Bearer <key>` upstream.
190
237
- If you want Codex to have access to a narrow set of privileged functionality, consider running a local MCP server that can perform these actions and configure Codex to use it.
0 commit comments