multica-ai/multica · error

create hermes memory store parent %s: %w

Error message

create hermes memory store parent %s: %w

What it means

Returned by newHermesStoreStaging when os.MkdirAll on the store's parent directory (<profile>/hermes-state/<agent>) fails. The staging dir must be a sibling of the store so the publish rename stays on one filesystem, so the parent has to exist first; failure aborts the memory (or session-db) migration.

Source

Thrown at server/internal/daemon/execenv/hermes_memory.go:264

		logger.Info("execenv: another task populated the hermes memory store first; keeping it", "store", storeDir)
		return nil
	}
	logger.Info("execenv: migrated task-local hermes memories into agent store", "store", storeDir, "entries", len(entries))
	return nil
}

// newHermesStoreStaging creates the scratch directory a store migration copies
// into. It is a sibling of the store so the promoting rename stays within one
// filesystem, and dot-prefixed so it is obvious it is not a store of its own.
// Shared by the memory migration here and the session-database migration in
// hermes_sessions.go: both delete their source once the copy reports success,
// so both need the same all-or-nothing publish.
// MkdirTemp already creates it 0700, the same mode the store itself is created
// with, so there is no follow-up chmod that could fail and strand it.
func newHermesStoreStaging(storeDir string) (string, error) {
	parent := filepath.Dir(storeDir)
	if err := os.MkdirAll(parent, 0o700); err != nil {
		return "", fmt.Errorf("create hermes memory store parent %s: %w", parent, err)
	}
	staging, err := os.MkdirTemp(parent, "."+filepath.Base(storeDir)+".migrating-")
	if err != nil {
		return "", fmt.Errorf("create hermes memory staging dir in %s: %w", parent, err)
	}
	return staging, nil
}

// promoteHermesStoreStaging publishes a fully-copied staging dir as the store,
// reporting whether this caller won. The empty store dir (if any) is removed
// first: os.Remove only succeeds on an empty directory, so a store another task
// already populated makes this a no-op, and Windows rejects a rename onto an
// existing directory outright.
//
// Losing the race is not an error — the winner's store holds the same agent's
// state — but it has to be positively confirmed, never inferred from any
// failure. The caller deletes the source directory whenever this returns
// (false, nil), so a permission error, a read-only filesystem or a Windows

View on GitHub (pinned to 2c0912b6ec)

Solutions

1. Fix ownership/permissions of ~/.multica and hermes-state for the daemon user.
2. Check disk space and inodes on the profile-dir volume.
3. Remove any regular file occupying the directory path named in the error.

if err := os.MkdirAll(filepath.Dir(storeDir), 0o700); err != nil {
    return fmt.Errorf("cannot prepare %s: %w", filepath.Dir(storeDir), err)
}

When it happens

Trigger: os.MkdirAll on the store parent fails: a component path exists as a file, profile dir read-only or full, or the daemon user lacks write permission anywhere along <profile>/hermes-state/<agent>.

Common situations: Same causes as store-creation failure: service-user mismatch on ~/.multica, full container volume, or a leftover file named like the agent segment blocking the directory chain.

Related errors

• remove stale memories path %s: %w
• read hermes memory store %s: %w
• read task-local hermes memories %s: %w
• mint PAT: response missing token
• daemon profile is not resolved yet; token sync skipped

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