I have been using codex (in agent canvas) for a bi...
# proj-agent
l
I have been using codex (in agent canvas) for a bit, and one thing codex is very good at is monitoring background processes. Instead of waiting for the process to complete, it will check on it every N seconds and possibly go off and do other things. It could be worth checking what they're doing there
😮 1
nod 2
@nutritious-balloon-65098 clone the codex and openhands/software-agent-sdk repos and see what i’m talking about, and propose a possible way of implementing this.
n
I'm on it! Graham Neubig can track my progress here.
Summary This was a research and analysis task — no code changes were made. The user asked me to clone the Codex and OpenHands SDK repos and investigate how Codex monitors background processes, then propose an implementation approach. What I found Codex's approach (in
codex-rs/core/src/unified_exec/
): • Uses two tools:
exec_command
(starts a PTY process) and
write_stdin
(sends input or polls with empty
chars
) • Both accept a
yield_time_ms
parameter — the LLM explicitly controls how long to wait before getting control back (250ms–30s range) • The output schema uses
session_id
presence as the "still running" signal
: if
session_id
is in the response, the process is still running and the LLM calls
write_stdin(session_id=X)
to check back. When done, only
exit_code
is present. • Yields are proactive and time-based — the LLM gets control back after N ms regardless of output activity OpenHands current behavior has all the machinery but with poor framing: •
timeout=N
already returns after N seconds with
exit_code=-1
(process keeps running) — this IS the yield mechanism, but it's described as "you'll be asked whether to continue or stop it" • The "still running" signal is buried in
exit_code=-1
, which also means errors • Yields are reactive (fire only after 30s of silence), not proactive Proposed implementation (three tiers) 1. Tier 1 — Update descriptions/messages: reframe
timeout
as a "soft yield interval" and
TIMEOUT_MESSAGE_TEMPLATE
as a positive status update rather than error language 2. Tier 2 — Add
still_running: bool
to
TerminalObservation
as an unambiguous signal (direct equivalent of Codex's
session_id
presence), set in the no-change and hard-timeout handlers 3. Tier 3 — Make
timeout
proactive (fire after N seconds regardless of output activity) instead of the current reactive no-change trigger — this is the actual behavioral parity with Codex's
yield_time_ms
l
@nutritious-balloon-65098 Okay open a PR with a new terminal tool that mimics this behavior and make sure that it is well tested by running actual live experiments. You can also exactly match the arguments of the codex terminal tool
n
I'm on it! Graham Neubig can continue tracking my progress here.
OpenHands encountered an error: **Failed to send message to agent server: HTTP 503 error: no available server ** See the conversation for more information.
s
FYI: would seem that "See the conversation" links to a conversation that I cannot
l
Yeah, only the person who invoked it can see the conversation
n
OpenHands encountered an error: **Failed to send message to agent server: HTTP 503 error: no available server ** See the conversation for more information.
c
GPT-5.x does it very well in OpenHands, too, I think maybe it’s a lot a model thing
l
True, but I'm specifically talking about the difference in monitoring background processes, codex is notably better
👍 1