* fix(exec ): stop emitting tool updates after session is backgrounded
When an exec session is backgrounded (background: true), the owning
agent run resolves its tool-call promise and may finish. The stdout
handler's emitUpdate() closure, however, kept invoking opts.onUpdate(),
delivering tool_execution_update events to a listener whose active run
had already ended. This surfaced as an unhandled rejection and crashed
the gateway process.
Guard emitUpdate() with a session.backgrounded || session.exited check
so that post-background output is still captured via appendOutput() but
no longer forwarded to the (now-stale) agent-loop callback.
Fixes#61592
* style: trim exec backgrounding comments
* fix: stop emitting post-background exec updates (#61627) (thanks @openperf)
* fix: place exec changelog entry at end of fixes (#61627) (thanks @openperf)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
After the node early-return, narrow workdir back to string via
resolvedWorkdir for gateway/sandbox paths. Update
buildExecApprovalPendingToolResult and buildApprovalPendingMessage
to accept string | undefined for cwd since node execution may omit it.
* fix(process): auto-detect PTY cursor key mode for send-keys
When a PTY session sends smkx (\x1b[?1h) or rmkx (\x1b[?1l) to switch
cursor key mode, send-keys now detects this and encodes cursor keys
accordingly.
- smkx/rmkx detection in handleStdout before sanitizeBinaryOutput
- cursorKeyMode stored in ProcessSession
- encodeKeySequence accepts cursorKeyMode parameter
- DECCKM_SS3_KEYS for application mode (arrows + home/end)
- CSI sequences for normal mode
- Modified keys (including alt) always use xterm modifier scheme
- Extract detectCursorKeyMode for unit testing
- Use lastIndexOf to find last toggle in chunk (later one wins)
Fixes#51488
* fix: fail loud when PTY cursor mode is unknown (#51490) (thanks @liuy)
* style: format process send-keys guard (#51490) (thanks @liuy)
---------
Co-authored-by: Ayaan Zaidi <hi@obviy.us>
When a command exits with code 127 (command not found) or 126 (not
executable), the exec tool previously returned status "completed" with
the error buried in the output text. This caused cron jobs to report
status "ok" and never increment consecutiveErrors, silently swallowing
failures like `python: command not found` across multiple daily cycles.
Now these shell-reserved exit codes are classified as "failed", which
propagates through the cron pipeline to properly increment
consecutiveErrors and surface the issue for operator attention.
Fixes#24587
Co-authored-by: Cursor <cursoragent@cursor.com>
(cherry picked from commit 2b1d1985ef)
Treat normal process exits (even with non-zero codes) as completed tool results.
This prevents standard exit codes (like grep exit 1) from being surfaced
as 'Tool Failure' warnings in the UI. The exit code is still appended
to the tool output for assistant awareness.
