Commit graph

20 commits

Author SHA1 Message Date
Ahmed Ibrahim
9b5078d3e8 Stabilize pipe process stdin round-trip test (#14013)
## What changed
- keep the explicit stdin-close behavior after writing so the child
still receives EOF deterministically
- on Windows, stop using `python -c` for the round-trip assertion and
instead run a native `cmd.exe` pipeline that reads one line from stdin
with `set /p` and echoes it back
- send `
` on Windows so the stdin payload matches the platform-native line
ending the shell reader expects

## Why this fixes flakiness
The failing branch-local flake was not in `spawn_pipe_process` itself.
The child exited cleanly, but the Windows ARM runner sometimes produced
an empty stdout string when the test used Python as the stdin consumer.
That makes the test sensitive to Python startup and stdin-close timing
rather than the pipe primitive we actually want to validate. Switching
the Windows path to a native `cmd.exe` reader keeps the assertion
focused on our pipe behavior: bytes written to stdin should come back on
stdout before EOF closes the process. The explicit `
` write removes line-ending ambiguity on Windows.

## Scope
- test-only
- no production logic change
2026-03-11 12:33:09 -07:00
Ahmed Ibrahim
52a7f4b68b Stabilize split PTY output on Windows (#14003)
## Summary
- run the split stdout/stderr PTY test through the normal shell helper
on every platform
- use a Windows-native command string instead of depending on Python to
emit split streams
- assert CRLF line endings on Windows explicitly

## Why this fixes the flake
The earlier PTY split-output test used a Python one-liner on Windows
while the rest of the file exercised shell-command behavior. That made
the test depend on runner-local Python availability and masked the real
Windows shell output shape. Using a native cmd-compatible command and
asserting the actual CRLF output makes the split stdout/stderr coverage
deterministic on Windows runners.
2026-03-11 12:33:07 -07:00
Andrei Eternal
244b2d53f4
start of hooks engine (#13276)
(Experimental)

This PR adds a first MVP for hooks, with SessionStart and Stop

The core design is:

- hooks live in a dedicated engine under codex-rs/hooks
- each hook type has its own event-specific file
- hook execution is synchronous and blocks normal turn progression while
running
- matching hooks run in parallel, then their results are aggregated into
a normalized HookRunSummary

On the AppServer side, hooks are exposed as operational metadata rather
than transcript-native items:

- new live notifications: hook/started, hook/completed
- persisted/replayed hook results live on Turn.hookRuns
- we intentionally did not add hook-specific ThreadItem variants

Hooks messages are not persisted, they remain ephemeral. The context
changes they add are (they get appended to the user's prompt)
2026-03-10 04:11:31 +00:00
Ahmed Ibrahim
5d9db0f995
Stabilize PTY Python REPL test (#13883)
## What changed
- The PTY Python REPL test now starts Python with a startup marker
already embedded in argv.
- The test waits for that marker in PTY output before making assertions.

## Why this fixes the flake
- The old version tried to probe the live REPL almost immediately after
spawn.
- That races PTY initialization, Python startup, and prompt buffering,
all of which vary across platforms and CI load.
- By having the child process emit a known marker as part of its own
startup path, the test gets a deterministic synchronization point that
comes from the process under test rather than from guessed timing.

## Scope
- Test-only change.
2026-03-09 10:08:36 -07:00
Eric Traut
a30edb6c17
Fix inverted Windows PTY TerminateProcess handling (#13989)
Addresses #13945

The vendored WezTerm ConPTY backend in
`codex-rs/utils/pty/src/win/mod.rs` treated `TerminateProcess` return
values backwards: nonzero success was handled as failure, and `0`
failure was handled as success.

This is likely causing a number of bugs reported against Codex running
on Windows native where processes are not cleaned up.
2026-03-08 11:52:16 -06:00
Ruslan Nigmatullin
5b04cc657f
utils/pty: add streaming spawn and terminal sizing primitives (#13695)
Enhance pty utils:
* Support closing stdin
* Separate stderr and stdout streams to allow consumers differentiate them
* Provide compatibility helper to merge both streams back into combined one
* Support specifying terminal size for pty, including on-demand resizes while process is already running
* Support terminating the process while still consuming its outputs
2026-03-06 15:13:12 -08:00
jif-oai
9a8adbf6e5
feat: use process group to kill the PTY (#12688)
Use the process group kill logic to kill the PTY
2026-02-24 16:55:23 +00:00
Eric Traut
10336068db
Fix flaky windows CI test (#10993)
Hardens PTY Python REPL test and make MCP test startup deterministic

**Summary**
- `utils/pty/src/tests.rs`
- Added a REPL readiness handshake (`wait_for_python_repl_ready`) that
repeatedly sends a marker and waits for it in PTY output before sending
test commands.
  - Updated `pty_python_repl_emits_output_and_exits` to:
    - wait for readiness first,
    - preserve startup output,
    - append output collected through process exit.
- Reduces Windows/ConPTY flakiness from early stdin writes racing REPL
startup.

- `mcp-server/tests/suite/codex_tool.rs`
- Avoid remote model refresh during MCP test startup, reducing
timeout-prone nondeterminism.
2026-02-07 08:55:42 -08:00
Eric Traut
82c981cafc
Process-group cleanup for stdio MCP servers to prevent orphan process storms (#10710)
This PR changes stdio MCP child processes to run in their own process
group
* Add guarded teardown in codex-rmcp-client: send SIGTERM to the group
first, then SIGKILL after a short grace period.
* Add terminate_process_group helper in process_group.rs.
* Add Unix regression test in process_group_cleanup.rs to verify wrapper
+ grandchild are reaped on client drop.

Addresses reported MCP process/thread storm: #10581
2026-02-06 21:26:36 -08:00
jif-oai
dc1b62acbd
feat: detach non-tty childs (#9477)
Thanks to the investigations made by
* @frantic-openai https://github.com/openai/codex/pull/9403
* @kfiramar https://github.com/openai/codex/pull/9388
2026-01-19 11:35:34 +00:00
jif-oai
2691e1ce21
fix: flaky tests (#9373) 2026-01-16 17:24:41 +01:00
jif-oai
1668ca726f
chore: close pipe on non-pty processes (#9369)
Closing the STDIN of piped process when starting them to avoid commands
like `rg` to wait for content on STDIN and hangs for ever
2026-01-16 15:54:32 +01:00
jif-oai
577e1fd1b2
feat: adding piped process to replace PTY when needed (#8797) 2026-01-14 18:44:04 +00:00
jif-oai
813bdb9010
feat: fallback unified_exec to shell_command (#8075) 2025-12-17 10:29:45 +00:00
jif-oai
f152b16ed9
fix: race on rx subscription (#7921)
Fix race where the PTY was sending first chunk before the subscription
to the broadcast
2025-12-12 12:40:54 +01:00
jif-oai
0ad54982ae
chore: rework unified exec events (#7775) 2025-12-10 10:30:38 +00:00
pakrym-oai
164265bed1
Vendor ConPtySystem (#7656)
The repo we were depending on is very large and we need very small part
of it.

---------

Co-authored-by: Pavel <pavel@krymets.com>
2025-12-09 17:23:51 +00:00
Pavel Krymets
f48d88067e
Fix unified_exec on windows (#7620)
Fix unified_exec on windows

Requires removal of PSUEDOCONSOLE_INHERIT_CURSOR flag so child processed
don't attempt to wait for cursor position response (and timeout).


https://github.com/wezterm/wezterm/compare/main...pakrym:wezterm:PSUEDOCONSOLE_INHERIT_CURSOR?expand=1

---------

Co-authored-by: pakrym-oai <pakrym@openai.com>
2025-12-05 20:09:43 +00:00
pakrym-oai
6c36318bd8
Use codex-linux-sandbox in unified exec (#6480)
Unified exec isn't working on Linux because we don't provide the correct
arg0.

The library we use for pty management doesn't allow setting arg0
separately from executable. Use the same aliasing strategy we use for
`apply_patch` for `codex-linux-sandbox`.

Use `#[ctor]` hack to dispatch codex-linux-sandbox calls.


Addresses https://github.com/openai/codex/issues/6450
2025-11-10 17:17:09 -08:00
jif-oai
5e4f3bbb0b
chore: rework tools execution workflow (#5278)
Re-work the tool execution flow. Read `orchestrator.rs` to understand
the structure
2025-10-20 20:57:37 +01:00