chenhg5/cc-connect · error

%s

Error message

%s

What it means

readLoop in agent/qoder/session.go emits a core.EventError containing the child process's stderr (or the exit error itself if stderr is empty) when the qoder process exits without producing any usable stream-json result. It is the adapter's way of propagating CLI-level failures (bad flags, auth errors, crashes) to the engine as an event rather than a Send return error.

Source

Thrown at agent/qoder/session.go:206

	// from hanging forever on the events channel.
	if len(nonJSONLines) > 0 {
		// qodercli produced plain text instead of stream-json; forward it
		// as a result so the user at least sees the response.
		slog.Warn("qoderSession: no result event, falling back to plain-text output", "lines", len(nonJSONLines))
		text := strings.Join(nonJSONLines, "\n")
		evt := core.Event{Type: core.EventResult, Content: text, SessionID: qs.CurrentSessionID(), Done: true}
		select {
		case qs.events <- evt:
		case <-qs.ctx.Done():
		}
	} else if exitErr != nil {
		// Process failed with no usable output.
		stderrMsg := strings.TrimSpace(stderrBuf.String())
		if stderrMsg == "" {
			stderrMsg = exitErr.Error()
		}
		slog.Error("qoderSession: process failed with no result", "error", exitErr, "stderr", truncStr(stderrMsg, 200))
		evt := core.Event{Type: core.EventError, Error: fmt.Errorf("%s", stderrMsg)}
		select {
		case qs.events <- evt:
		case <-qs.ctx.Done():
		}
	} else if scanErr != nil {
		// Scanner error with no output.
		evt := core.Event{Type: core.EventError, Error: fmt.Errorf("read stdout: %w", scanErr)}
		select {
		case qs.events <- evt:
		case <-qs.ctx.Done():
		}
	} else {
		// Process exited cleanly but produced nothing at all.
		slog.Warn("qoderSession: process exited with no output and no result event")
		evt := core.Event{Type: core.EventResult, Content: "", SessionID: qs.CurrentSessionID(), Done: true}
		select {
		case qs.events <- evt:
		case <-qs.ctx.Done():

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Read the event's Error text — it is the trimmed stderr from the CLI — and fix the reported cause
  2. Run the qoder command manually with the same args (-p ... -f stream-json -q -w workDir) to reproduce
  3. Re-authenticate the qoder CLI (login/API key) if the stderr mentions auth
  4. Pin or update the qoder CLI version if flags changed
  5. Check exit status/OOM (dmesg) if stderr is empty and the message is just the exit error

Example fix

// diagnose
//   event error: "unknown flag: -f"
// fix: align CLI version with expected flags
qoder -p "hi" -f stream-json -q -w .   # verify manually before blaming the adapter
Defensive patterns

Strategy: try-catch

Validate before calling

// before sending, verify the CLI accepts the flags:
// exec.Command("qodercli", "-f", "stream-json", "-q").Run()

Try / catch

for evt := range sess.Events() {
    if evt.Type == core.EventError {
        slog.Error("qoder CLI failed", "stderr", evt.Error)
        // notify user and optionally recreate the session
    }
}

Prevention

When it happens

Trigger: qoder process exits non-zero with no parsed output events: invalid CLI flags/version mismatch, expired or missing qoder auth, CLI crash, or exitErr non-nil with empty stdout stream and non-scanner cause.

Common situations: qoder CLI updated and stream-json flags changed; API key/login expired so the CLI prints an auth error to stderr; OOM-kill or signal terminating the process mid-turn; running an unsupported qoder version.

Related errors


AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/0c02d6d996b29207. Report an issue: GitHub.