chenhg5/cc-connect · error

codex app-server initialized notify: %w

Error message

codex app-server initialized notify: %w

What it means

This error wraps a failure of the JSON-RPC "initialized" notification sent after a successful "initialize" response, completing the LSP-style handshake with the codex app-server. Failing here means the transport broke between initialize and the notification — typically the app-server process died or closed its stdin. Initialize itself succeeded, so the protocol version is compatible but the connection dropped.

Source

Thrown at agent/codex/appserver_session.go:319

		"capabilities": map[string]any{
			"experimentalApi": true,
			"optOutNotificationMethods": []string{
				"command/exec/outputDelta",
				"item/agentMessage/delta",
				"item/plan/delta",
				"item/fileChange/outputDelta",
				"item/reasoning/summaryTextDelta",
				"item/reasoning/textDelta",
			},
		},
	}

	var resp initResponse
	if err := s.request("initialize", params, &resp); err != nil {
		return fmt.Errorf("codex app-server initialize: %w", err)
	}
	if err := s.notify("initialized", nil); err != nil {
		return fmt.Errorf("codex app-server initialized notify: %w", err)
	}
	return nil
}

func (s *appServerSession) ensureThread(resumeID string) error {
	if resumeID != "" && resumeID != core.ContinueSession {
		params := s.threadRequestParams()
		params["threadId"] = resumeID
		params["persistExtendedHistory"] = true

		var resp threadResumeResponse
		if err := s.request("thread/resume", params, &resp); err != nil {
			return err
		}
		if resp.Thread.ID == "" {
			return fmt.Errorf("codex app-server resume returned empty thread id")
		}
		s.applyThreadRuntimeState(resp.Cwd, resp.Model, resp.ReasoningEffort)

View on GitHub (pinned to 4000b2338a)

Solutions

1. Inspect app-server stderr for a crash immediately after initialize; fix the underlying cause.
2. Check for concurrent Close/Stop calls racing with startup and serialize session lifecycle.
3. Retry StartSession once — a transient crash during handshake is often environmental.
4. Update or reinstall the codex CLI if crashes are reproducible across initialize cycles.

Example fix

// before
if err := s.notify("initialized", nil); err != nil {
    return fmt.Errorf("codex app-server initialized notify: %w", err)
}
// after
if err := s.notify("initialized", nil); err != nil {
    if !s.alive.Load() {
        return fmt.Errorf("codex app-server initialized notify: session closed during handshake: %w", err)
    }
    return fmt.Errorf("codex app-server initialized notify: %w", err)
}

// Ensure no concurrent teardown is possible before starting the session
if !sessionLifecycleMu.TryLock() {
    return errors.New("session close/start race detected; serialize lifecycle")
}

if err := session.Start(ctx); err != nil {
    if strings.Contains(err.Error(), "initialized notify") {
        // initialize succeeded but the pipe died: child crashed post-init
        slog.Error("codex app-server died after initialize; inspect stderr", "err", err)
    }
    return err
}

When it happens

Trigger: Calling StartSession on the codex agent; s.notify("initialized", nil) fails because the app-server exited right after initialize (crash in its post-initialize path), or the pipe writes fail (broken pipe/timeout).

Common situations: App-server crash triggered by initialize response handling; race where Close() is called concurrently during startup; fd/pipe issues under resource pressure; flaky sandbox blocking further IPC.

Related errors

• codex app-server initialize: %w
• acp: initialize: %w
• acp: authenticate (%s): %w
• acp: session/new: %w
• write hook response: %w

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