What causes "status "all" cannot be combined with other statuses" in gastownhall/beads?

Use "--status all" alone to list every status

status "all" cannot be combined with other statuses

Error message

status "all" cannot be combined with other statuses

What it means

In a comma-separated multi-status selector, "all" is only meaningful alone (it means every status). Combining "all" with other statuses is ambiguous and rejected with this dedicated message rather than the generic invalid-status error.

Source

Thrown at internal/workapi/list.go:521

func applyStatusParts(filter *types.IssueFilter, parts []string, customStatusNames []string) error {
	if len(parts) == 1 {
		s := types.Status(parts[0])
		if !s.IsValidWithCustom(customStatusNames) {
			return fmt.Errorf("invalid status %q (valid: %s)", parts[0], ValidStatusList(customStatusNames))
		}
		filter.Status = &s
		return nil
	}

	for _, part := range parts {
		s := types.Status(part)
		if !s.IsValidWithCustom(customStatusNames) {
			// "all" is a real selector on its own (every status), so failing
			// it as merely "invalid" would contradict the flag help. A custom
			// status literally named "all" passes validation above instead.
			if part == "all" {
				return fmt.Errorf(`status "all" cannot be combined with other statuses`)
			}
			return fmt.Errorf("invalid status %q in multi-status filter (valid: %s)", part, ValidStatusList(customStatusNames))
		}
		filter.Statuses = append(filter.Statuses, s)
	}
	return nil
}

View on GitHub (pinned to 71377f2769)

Solutions

Use "--status all" alone to list every status
Remove the "all" part and list the concrete statuses you want, e.g. "open,in_progress"
Use the --all flag instead of --status all if that is what you meant
Note: a custom status literally named "all" is allowed only as a single-part selector

Example fix

// before
bd list --status all,open
// after
bd list --status all   # or: bd list --status open,in_progress

Defensive patterns

Strategy: validation

Validate before calling

parts := strings.Split(status, ",")
if len(parts) > 1 {
    for _, p := range parts {
        if strings.TrimSpace(p) == "all" {
            return fmt.Errorf("use --status all alone")
        }
    }
}

Try / catch

err := workapi.ApplyStatusFilter(&filter, status, customNames)
if strings.Contains(err.Error(), "cannot be combined") {
    return fmt.Errorf("pass --status all alone, or list concrete statuses")
}

Prevention

Never combine "all" with other statuses in a selector
Treat "all" as a standalone selector in UIs and scripts
Build status lists programmatically and strip "all" from multi-selects
Document that a custom status named "all" only works as a sole selector

When it happens

Trigger: Calling ApplyStatusFilter or BuildListFilter with a status string like "all,open" or "open,all,closed" — a multi-part selector where one part is the literal "all".

Common situations: Users typing `bd list --status all,open` expecting OR semantics; scripts appending "all" to an existing status list; confusion between --all flag and --status all.

Related errors

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