What causes "resolve profile %q: %w" in multica-ai/multica?

Inspect the wrapped error for the OS cause (permission denied, no such file, etc.).

resolve profile %q: %w

Error message

resolve profile %q: %w

What it means

requireKnownProfile first checks whether the given daemon profile exists (profileExists). If that check itself errors — typically a filesystem failure reading the profiles/ directory — the failure is wrapped as 'resolve profile %q: %w'. This is not 'unknown profile' (that path returns unknownProfileError separately after listing); it means the existence probe broke.

Source

Thrown at server/cmd/multica/cmd_daemon.go:499

// a flat "stopped" — indistinguishable from a daemon that is genuinely not
// running, even while the correctly-named daemon serves happily on another
// port (#6694). Failing loudly with the known names turns that dead end into a
// one-glance fix.
//
// The default profile is never validated: it owns ~/.multica directly, has no
// entry under profiles/, and is always legitimate.
//
// Callers must invoke this AFTER their daemon-managed-task guard
// (requireHumanLocalCommand, or daemonStatusHealthPort for status). Listing the
// profiles root inside a task would disclose the Owner's profile names, which
// those guards exist to prevent.
func requireKnownProfile(profile string) error {
	if profile == "" {
		return nil
	}
	exists, err := profileExists(profile)
	if err != nil {
		return fmt.Errorf("resolve profile %q: %w", profile, err)
	}
	if exists {
		return nil
	}
	// Only now is the listing worth its disk walk, and only now can it be
	// wrong in a way the user sees.
	names, err := knownProfiles()
	if err != nil {
		return fmt.Errorf("list profiles: %w", err)
	}
	return &unknownProfileError{Profile: profile, Known: names}
}

// --- daemon start ---

// daemonExecutable resolves the binary to spawn as the background daemon
// child. Tests override it: spawning the resolved executable there would fork
// the test binary itself, which ignores the daemon args and re-runs the suite.

View on GitHub (pinned to 2c0912b6ec)

Solutions

Inspect the wrapped error for the OS cause (permission denied, no such file, etc.).
Fix permissions/ownership on the profiles directory (e.g. chmod/chown the daemon config root).
Run the same command without --profile to confirm the base config path is healthy, then re-create the profile.

Example fix

# before: running as wrong user
sudo multica daemon status --profile work
# after
multica daemon status --profile work

Defensive patterns

Strategy: validation

Validate before calling

# verify the profiles dir is readable before daemon commands
PROFILES_ROOT="${XDG_CONFIG_HOME:-$HOME/.config}/multica/profiles"
test -r "$PROFILES_ROOT" && test -x "$PROFILES_ROOT" \
  || { echo "profiles dir unreadable: $PROFILES_ROOT" >&2; exit 2; }
multica daemon status --profile work

Try / catch

err := runDaemonCmd()
if err != nil && strings.Contains(err.Error(), "resolve profile") {
    // filesystem-level: inspect inner error with errors.Unwrap for EACCES/ENOENT
    // do NOT treat as 'unknown profile' — that has its own unknownProfileError type
}

Prevention

Run daemon commands as the user that owns the config/profiles directory.
After moving or restoring a home dir, re-check ownership of the profiles root before starting the daemon.

When it happens

Trigger: Profiles directory unreadable (permissions changed, disk error), path type conflict (a file where a directory is expected), or OS-level I/O errors while running a daemon command with --profile <name>.

Common situations: Profiles root moved or its permissions tightened after setup; running under a different user (sudo vs normal) that cannot read the profiles dir; partially deleted state from a crashed uninstall.

Related errors

AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/b11da11f9268d5ee. Report an issue: GitHub.