Desktop: host stderr is never forwarded (only kept in a 64KB in-memory buffer), so plugin warnings/errors are invisible while the host runs

[lyosvne]

Version: desktop shell bundling dsh 0.1.7 (macOS, launched via launchd); same code on main in apps/desktop/src/host-process.ts.

What happens
In DesktopHostProcess.start() the host is spawned with stdio: ['ignore', 'pipe', 'pipe', 'ipc']. stdout is forwarded (child.stdout?.pipe(process.stdout)), but stderr is only appended to an in-memory ring buffer:

child.stderr?.on('data', (chunk: string) => { this.stderr = (this.stderr + chunk).slice(-MAX_HOST_DIAGNOSTIC_CHARS) })

That buffer is only read when the host exits (as the suffix of "dsh desktop host exited/stopped"). While the host is running, nothing written to stderr reaches the desktop process's stderr or any log file.

Impact
Plugins that report failures through console.warn / console.error (and cordis loggers that write to stderr) are silent in a running desktop. In our case a scheduled plugin job failed repeatedly for about 5 hours and the only signal was a console.warn that never appeared in the shell's log, while console.log lines from the same plugin did.

Expected
Runtime stderr from the host should be observable in the desktop's log, in the same way stdout already is.

Suggestion

• Forward stderr the same way stdout is forwarded (child.stderr?.pipe(process.stderr)), keeping the existing tail buffer for exit diagnostics; or
• if forwarding is avoided on purpose (the comment near the unclean-exit error notes that plugin stderr may contain credentials), forward it only when a setting or env flag is enabled. Today stdout is already forwarded unfiltered, so the credentials concern applies to stdout as well; it doesn't seem to be a reason to drop stderr specifically.

[argszero]

The host's stderr is not the only channel a plugin has

Your reading of apps/desktop/src/host-process.ts matches what I see on main: child.stdout?.pipe(process.stdout) forwards one stream, and stderr only feeds the ring buffer that is read when the host exits. For plugins that is the difference between "the failure was reported" and "the failure was observable".

There is a second channel a plugin can own, independent of the host's stdio: the cordis logger. ctx.logger.exporter(sink) (vendor/cordis/src/logger.ts:232) registers a sink on the process-wide LoggerService — child contexts are Object.create-derived (vendor/cordis/src/context.ts:99) and the service is constructed once on the root (:81), so a sink registered from any context receives every message logged anywhere in the tree, including the loader's own errors (vendor/loader/src/config/entry.ts:228). LoggerService also retains a built-in ring buffer (1000 messages, logger.ts:195-221), so a plugin mounted late can still read back what was logged before it existed.

Measured with cordis 4.0.4 + cordis-plugin-loader 1.0.6-alpha.1: a sink registered on a child context received 5/5 messages logged from the root, another child and a grandchild, and with a real Loader it received { type: 'error', name: 'loader', args: [Error] } where args[0] instanceof Error is true — original message and stack intact.

So "plugin diagnostics are invisible in a running desktop" has a plugin-side answer: a diagnostic plugin can sink these messages and write them to a file it owns, readable while the host is still running — no change to host-process.ts required. That is a workaround for the observability gap, not for the asymmetry you identify: stderr from the host should reach the desktop's log exactly as stdout already does, and the credentials argument does not survive your own observation that stdout is forwarded unfiltered today.

One boundary worth stating in this thread: such a sink sees what goes through the cordis logger. A plugin that writes to process.stderr directly is invisible to it — which is the case your report is about, so the core fix you suggest is still the one that closes it.