[Bug]: codemode manager can stay disposed after Senpi RPC lifecycle teardown, surfacing as exit code 143

[MingyooLee]

Summary

I am seeing repeated session interruptions where the user-visible error is:

[System Error] Pi RPC process exited with code 143 and signal null

Around the same failures, eval/codemode calls surface:

codemode session manager is disposed

Restarting the host application temporarily restores the session, but the same failure returns later. Based on the installed code and current main, this looks like a Senpi RPC/codemode lifecycle recovery issue rather than 143 itself being the root cause.

Environment

• OmO package: 5.0.0-0.beta.62
• Embedded Senpi package: @code-yeongyu/senpi 2026.9.13
• Embedded codemode package: @code-yeongyu/senpi-codemode 2026.9.13
• Upstream checked: code-yeongyu/senpi main, packages/senpi-codemode reports 2026.9.13-2
• OS: macOS / Darwin arm64
• Runtime observed in package metadata: Node.js >=24.0.0; local Bun is 1.4.0

Observed evidence

From the affected local session transcript:

2026-09-14T11:26:09.885Z  toolResult: codemode session manager is disposed
2026-09-14T13:49:42.326Z  toolResult: codemode session manager is disposed
2026-09-15T00:33:01.996Z  toolResult: codemode session manager is disposed
2026-09-15T00:44:03.498Z  toolResult: codemode session manager is disposed

There was also a provider stream-start timeout near this time in local logs, but I currently think that is a separate issue rather than the interruption reported here. I am not treating it as a root cause or trigger for this report. The recurring user-visible failure is that the runtime does not recover cleanly and later work is interrupted with the RPC exit / disposed codemode state.

Code-path evidence

Installed Senpi RPC code makes 143 consistent with a SIGTERM lifecycle shutdown:

• dist/modes/rpc/rpc-mode.js: the SIGTERM handler calls shutdown(143, signal).
• dist/modes/rpc/host-lifecycle.js: stopChild(child) sends child.kill("SIGTERM") before escalating to SIGKILL.

Installed and upstream codemode code makes the disposed error path explicit:

• packages/senpi-codemode/src/extension/session-manager.ts
  • CodemodeSessionDisposedError message is exactly codemode session manager is disposed.
  • getKernel() throws CodemodeSessionDisposedError when #disposePromise exists.
• packages/senpi-codemode/src/index.ts
  • dropRuntime() clears active runtime/cells/context and calls await manager.dispose().
  • Current upstream main still has pi.on("session_shutdown", async () => dropRuntime()) without inspecting the shutdown reason.
  • Current upstream main also drops runtime on session_before_switch and session_before_fork.

I also noticed the related note in code-yeongyu/senpi#463:

Follow-up (separate PR): senpi-codemode drops its eval kernel on any session_shutdown, same defect class.

That note appears to match the failure shape here: the runtime is disposed by a session/RPC lifecycle event, then subsequent eval/codemode usage surfaces codemode session manager is disposed and the host reports the RPC process exit.

Expected behavior

One of these should happen instead:

1. codemode preserves or parks the eval runtime across lifecycle events where the session is expected to continue, similar to the terminal-session fix in fix(coding-agent): preserve terminal sessions and monitors across reload #463; or
2. codemode reliably creates a fresh manager/runtime on the next usable session_start / eval call after a lifecycle teardown; or
3. the RPC/session boundary reports a handled, actionable lifecycle error instead of leaving the user in a recurring broken state.

What I am not claiming

• I am not claiming exit code 143 itself is abnormal. The code suggests it is the expected exit code for a SIGTERM shutdown.
• I am not claiming the provider stream-start timeout is necessarily the root cause.
• I do not yet have a deterministic standalone reproduction that identifies the exact parent process or event that sends the SIGTERM.

The bug report is about the recovery/lifecycle boundary: after the runtime is torn down, work is repeatedly interrupted and codemode remains or becomes disposed from the user's point of view.

Requested confirmation

Could you confirm whether senpi-codemode is expected to dispose on every session_shutdown, or whether shutdown reasons such as reload/reconnect-like host lifecycle events should park/rebind the codemode runtime the same way terminal sessions were handled in #463?