What causes "loading status configuration: %w" in gastownhall/beads?

Look at the wrapped cause (%w) for the underlying error — fix that first.

loading status configuration: %w

Error message

loading status configuration: %w

What it means

humanIssues (the direct-store path behind `bd human` / `bd human list`) calls workapi.LoadStoreListConfig to load the status/list configuration used to build the human-list filter. This error wraps any failure loading that per-store configuration, so the command aborts before querying issues.

Source

Thrown at cmd/bd/human.go:165

		printHumanList(issues)
		return nil
	},
}

// humanIssues loads the human-labeled beads matching the status selector
// through whichever backend this invocation uses: the direct store, or a
// proxied-server unit of work. Both routes apply the same humanListFilter.
func humanIssues(ctx context.Context, status string) ([]*types.Issue, error) {
	if usesProxiedServer() {
		return proxiedHumanIssues(ctx, status)
	}

	if err := ensureStoreActive(); err != nil {
		return nil, err
	}
	cfg, err := workapi.LoadStoreListConfig(ctx, store)
	if err != nil {
		return nil, fmt.Errorf("loading status configuration: %w", err)
	}
	filter, err := humanListFilter(status, cfg)
	if err != nil {
		return nil, err
	}
	return store.SearchIssues(ctx, "", filter)
}

// humanListRequest builds the list request for "human list": every
// human-labeled bead regardless of type — a human label is an explicit
// request for a person's attention, and this command is the only place a
// person sees it, so gates, wisps, infra beads, and templates all show.
// Status filtering matches `bd list`: done/frozen statuses and pinned beads
// are hidden by default, an explicit --status selects specific statuses
// (validated against the built-in and custom status names), and "all" lifts
// the status defaults entirely.
func humanListRequest(status string) issueops.ListRequest {
	unlimited := 0

View on GitHub (pinned to 71377f2769)

Solutions

Look at the wrapped cause (%w) for the underlying error — fix that first.
Run `bd doctor` to diagnose database/config health.
Back up and check the .beads directory; restore from .beads/issues.jsonl or a fresh clone/sync if corrupt.
Ensure the bd version matches the data (upgrade/downgrade bd if versions differ).
Retry `bd human` after repair.

Example fix

// before
$ bd human
// error: loading status configuration: ... (underlying db/config failure)
// after
$ bd doctor        # diagnose
$ bd dolt pull     # or restore from backup
$ bd human

Defensive patterns

Strategy: try-catch

Validate before calling

if _, err := os.Stat(filepath.Join(".beads", "beads.db")); err != nil {
    return fmt.Errorf("no beads store found in .beads; run bd init or sync first")
}

Try / catch

issues, err := humanIssues(ctx, status)
if err != nil {
    if strings.Contains(err.Error(), "loading status configuration") {
        log.Printf("run bd doctor to repair the store/config: %v", err)
    }
    return err
}

Prevention

Keep bd versions consistent between machines sharing a beads store
Run bd doctor periodically to catch store/config corruption early
Back up .beads before risky operations and prefer clean sync over manual edits

When it happens

Trigger: `bd human` (or humanIssues via the anonymous cobra RunE) with the direct (non-proxied) store active, where LoadStoreListConfig fails: unreadable/corrupt status configuration in the store/database, database open or migration failure, or schema problems in the config source.

Common situations: Corrupted .beads database after a crash; version mismatch where an older bd reads a config written by a newer one; read-only filesystem preventing config load; partial sync leaving inconsistent config rows.

Related errors

AI-assisted analysis of gastownhall/beads@71377f2769 (2026-08-30). Data as JSON: /api/errors/9266515c4c492b80. Report an issue: GitHub.