End all sessions when the opencode process is killed

[gtrrz-victor]

Entire-Checkpoint: d4c504e45799

[cursor]

PR Summary

Medium Risk
Introduces a new background child process and IPC that triggers session cleanup on parent exit, which could affect reliability or performance if the watcher misbehaves.

Overview
Ensures OpenCode sessions are properly closed even if the OpenCode process is abruptly terminated.

The plugin now spawns a background "cleanup watcher" child process and tracks active session IDs; when the parent exits and the stdin pipe closes, the watcher invokes entire hooks opencode session-end for any remaining tracked sessions. Session lifecycle handling is updated to track on session.created and untrack on session.deleted.

^{Written by Cursor Bugbot for commit 570bc11. Configure here.}

[Copilot]

Pull request overview

This PR adds a cleanup mechanism to ensure OpenCode sessions are properly ended when the OpenCode process is killed unexpectedly. The solution spawns a child Node.js process that monitors the parent via stdin pipe - when the parent exits (and the pipe closes), the child calls entire hooks opencode session-end for all tracked sessions.

Changes:

• Implements a process-based cleanup watcher using Bun.spawn and a child Node.js process
• Tracks active sessions via IPC messages over stdin/stdout
• Automatically cleans up orphaned sessions when the parent process exits

[Copilot]

The child process's stdin handlers accumulate data in buf without any size limit. A malicious or buggy parent could send an unbounded amount of data before closing stdin, causing the child process to consume excessive memory. Consider adding a maximum buffer size and discarding or rejecting data once the limit is reached.

[Copilot]

There is a potential race condition between session-start/session-end events and the cleanup watcher. If a session-end event occurs normally (via session.deleted) and untrack() is called at line 156, but the parent process is killed before the untrack message is processed by the child, the child may still attempt to clean up the already-ended session. While the try-catch at line 31 will suppress errors, this could result in unnecessary processing or duplicate session-end calls. Consider adding idempotency checks on the Go side to handle duplicate session-end calls gracefully.

[Copilot]

If OpenCode is restarted while sessions are still active, the cleanup watcher is spawned fresh without knowledge of pre-existing sessions. If the OpenCode process is then killed, those pre-existing sessions will not be cleaned up because they were never tracked by the watcher. Consider implementing a mechanism to discover and track existing sessions when the plugin initializes, or document this limitation.

Suggested change

	const messageStore = new Map<string, any>()
	const messageStore = new Map<string, any>()
	// NOTE: The cleanup watcher only tracks sessions reported during the lifetime
	// of this plugin instance. If OpenCode is restarted while sessions are still
	// active, those pre-existing sessions will not be known to this watcher and
	// may not receive automatic session-end cleanup if the process then exits.

[Copilot]

The child process spawned by Bun.spawn will become a zombie process when the parent exits, as there is no mechanism to reap it. The child process will terminate when stdin closes, but it will remain as a zombie until a parent process reaps it (calls wait). Consider using the detached: true option in Bun.spawn and calling child.unref() to allow the child to run independently and avoid zombie processes.

Suggested change

	stderr: "ignore",
	});
	stderr: "ignore",
	detached: true,
	});
	// Allow the watcher process to run independently and avoid zombie processes.
	child.unref();

[Copilot]

The write to child.stdin at line 48 could fail if the child process has already exited or if the pipe is broken. While the try-catch suppresses the error, this means that track/untrack calls could silently fail, leading to sessions not being cleaned up. Consider logging these failures or implementing a retry mechanism for critical operations like tracking new sessions.

Suggested change

	try { child.stdin.write(JSON.stringify({ type, id }) + "\n"); child.stdin.flush(); } catch { }
	};
	return {
	track: (id: string) => send("track", id),
	untrack: (id: string) => send("untrack", id),
	};
	} catch {
	try {
	child.stdin.write(JSON.stringify({ type, id }) + "\n");
	child.stdin.flush();
	} catch (err) {
	// Log (but do not rethrow) so failed tracking doesn't remain silent
	console.error("[entire-plugin] failed to send session tracking message to cleanup watcher:", err);
	}
	};
	return {
	track: (id: string) => send("track", id),
	untrack: (id: string) => send("untrack", id),
	};
	} catch (err) {
	// If the watcher process cannot be started, log and fall back to no-op tracking
	console.error("[entire-plugin] failed to spawn cleanup watcher process:", err);

[Copilot]

The comment states that the child process handles SIGKILL, but this is incorrect. SIGKILL cannot be caught or handled by any process - it immediately terminates the process without allowing any cleanup. What actually happens is that when the parent process is terminated (by any signal including SIGKILL), the pipe closes, which triggers the 'end' event on stdin. The comment should be corrected to accurately describe this mechanism.

[Copilot]

The code assumes that the 'node' command is available in the system PATH, but there is no validation or graceful degradation if Node.js is not installed. While the outer try-catch at line 41 will catch spawn failures and return no-op functions, this could lead to silent failures where sessions are never cleaned up. Consider adding a comment explaining this fallback behavior, or implementing a one-time check/warning to notify users if node is not available.

[Copilot]

The watcher tracks sessions when session.created fires, but if the track() call fails silently (e.g., child process already exited), and then the OpenCode process is killed before a normal session-end event, the session will be orphaned and not cleaned up. Consider adding validation or logging to detect when the watcher fails to initialize or track sessions, so users are aware of potential cleanup issues.