plandex-ai/plandex · error

error getting plan settings: %v

Error message

error getting plan settings: %v

What it means

Despite the 'plan settings' wording, this error is the panic-recovery branch of the goroutine that calls active.PendingBuildsByPath in loadPendingBuilds (build_load.go). The defer/recover block catches any panic (nil map write, nil pointer dereference, etc.) inside that goroutine and reports it as 'error getting plan settings: %v' with the recovered value, then calls runtime.Goexit to avoid double-sending on errCh. So seeing this message means the pending-builds goroutine panicked, not that settings failed. The recovered value after '%v' is the panic cause.

Source

Thrown at app/server/model/plan/build_load.go:72

					runtime.Goexit() // don't allow outer function to continue and double-send to channel
				}
			}()
			res, err := db.GetPlanContexts(auth.OrgId, plan.Id, true, false)
			if err != nil {
				log.Printf("Error getting plan modelContext: %v\n", err)
				errCh <- fmt.Errorf("error getting plan modelContext: %v", err)
				return
			}
			modelContext = res

			errCh <- nil
		}()

		go func() {
			defer func() {
				if r := recover(); r != nil {
					log.Printf("panic in getPlanSettings: %v\n%s", r, debug.Stack())
					errCh <- fmt.Errorf("error getting plan settings: %v", r)
					runtime.Goexit() // don't allow outer function to continue and double-send to channel
				}
			}()
			res, err := active.PendingBuildsByPath(auth.OrgId, auth.User.Id, nil)

			if err != nil {
				log.Printf("Error getting pending builds by path: %v\n", err)
				errCh <- fmt.Errorf("error getting pending builds by path: %v", err)
				return
			}

			pendingBuildsByPath = res

			errCh <- nil
		}()

		go func() {
			defer func() {

View on GitHub (pinned to e2d772072e)

Solutions

  1. Check server logs for 'panic in getPlanSettings' followed by the stack trace - it identifies the exact nil dereference or assertion that panicked.
  2. Check the log lines just before it for 'Error activating plan' - a failed activatePlan leaves 'active' partially initialized; fix that activation error first.
  3. Upgrade plandex-server (and plandex CLI) to matching latest versions; this panic path was likely fixed in newer releases.
  4. Retry the operation after confirming the plan/branch state is valid (plandex branches, plandex builds).
  5. If reproducible, capture the stack trace and report it to Plandex - a panic here is an internal bug, not user error.

Example fix

// before (server code that lets a failed activation produce a nil-dependent panic)
active, err := activatePlan(clients, plan, branch, auth, "", true, false, sessionId)
if err != nil {
    log.Printf("Error activating plan: %v\n", err)
}
// after
active, err := activatePlan(clients, plan, branch, auth, "", true, false, sessionId)
if err != nil {
    errCh <- fmt.Errorf("error activating plan: %v", err)
    return err
}
Defensive patterns

Strategy: try-catch

Validate before calling

// before triggering the build, confirm the plan activated cleanly
// plandex ps --plan <planId>   -> plan exists and branch is valid
// check server logs for 'Error activating plan' before/at request time

Try / catch

err := loadPlanBuild(planId)
if err != nil {
    if strings.Contains(err.Error(), "error getting plan settings") {
        // ambiguous message: check server logs for 'panic in getPlanSettings'
        // + stack trace to confirm it was a panic in the pending-builds goroutine,
        // then retry or report upstream with the stack
        return fmt.Errorf("internal server panic while loading plan: %w", err)
    }
    return err
}

Prevention

When it happens

Trigger: Any panic inside the goroutine that wraps active.PendingBuildsByPath(orgId, userId, nil) - typically a nil receiver/plan-state field (e.g. 'active' or an internal map is nil because activatePlan failed upstream) or an unexpected type assertion while computing pending builds by path.

Common situations: activatePlan on line 23 failed (its error is only logged, not returned) leaving 'active' partially initialized; concurrent mutation of plan state; a bug triggered by a plan with zero pending builds or an unusual branch state; running a server build with mismatched plandex-server/shared versions.

Related errors

AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05). Data as JSON: /api/errors/e9b837d65bc1ff94. Report an issue: GitHub.