jdx/mise · error
cannot set up from a setup repository
Error message
cannot set up from a setup repository: {reason} What it means
During `mise ssh` setup from a setup repository, mise opens the local history checkpoint Store before onboarding. If the store reports itself unavailable (`store.unavailable()` returns a reason — e.g. the history store cannot be opened or initialized), mise aborts the onboarding with the underlying reason. This prevents onboarding runs against a history store that cannot record checkpoints.
Solutions
- Read the {reason} in the message and fix the underlying store issue (permissions, disk space, corrupt files).
- Repair or clear the history checkpoint store directory, then retry.
- If history is not needed, disable/ignore the onboarding step or skip syncing history from the setup repository.
Example fix
// before: history store unusable mise ssh --setup-repo ... // cannot set up from a setup repository: <reason> // after: fix store location/permissions (e.g. make history dir writable) chmod u+w ~/.local/share/mise/history mise ssh --setup-repo ...
Defensive patterns
Strategy: retry
Validate before calling
test -w "${MISE_HISTORY_DIR:-$HOME/.local/share/mise/history}" || echo 'history store not writable' >&2 Try / catch
mise ssh --setup-repo ... || { echo "onboard failed: $? — fix history store then retry" >&2; } Prevention
- Ensure the history/checkpoint store directory exists and is writable in containers and CI
- Repair or clear a corrupted store after crashes before re-running setup
- Skip history sync if the environment intentionally disables history
When it happens
Trigger: Running `mise ssh` setup from a setup repository where `Store::open()` succeeds but the store reports an unavailability reason — corrupted or unwritable history store, unsupported storage location, or history disabled in this environment.
Common situations: Running in containers/CI where the history directory is read-only or missing; a corrupted checkpoint store from a previous crash; environments where the history feature is intentionally disabled.
Understand the failure class
Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.
Related errors
- a repository preview directory requires a dry run
- cannot connect a setup repository
- cannot nest relay sessions
- declined; nothing was changed
- GitHub relay requires a POSIX target
AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17).
Data as JSON: /api/errors/6e136eafebc5a056.
Report an issue: GitHub.
Appendix: source
Thrown at src/cli/ssh.rs:95
);
return Ok(());
}
if let Some(bundle) = self.repository_bundle {
let origin = self
.repository_origin
.ok_or_else(|| eyre::eyre!("missing repository origin"))?;
let revision = self
.repository_revision
.ok_or_else(|| eyre::eyre!("missing repository revision"))?;
// a history-managed setup repository is set up from, never
// checked out into the configuration directory
if let Some(branch) =
crate::system::remote_repository::history_branch(&bundle, &revision)?
{
use crate::system::history::sync::onboard;
let store = crate::system::history::checkpoint::Store::open()?;
if let Some(reason) = store.unavailable() {
bail!("cannot set up from a setup repository: {reason}");
}
let fetch_from = bundle.to_string_lossy().into_owned();
let outcome = onboard::run(
&store,
&onboard::Onboarding {
fetch_from,
origin,
branch,
yes: self.repository_yes,
dry_run: self.repository_dry_run,
replace_history: false,
},
)
.await?;
if let Some(directory) = &self.repository_preview_directory {
let preview = outcome
.preview_config
.as_ref()View on GitHub (pinned to 533346cc37)