Troubleshooting

This page lists common problems with the exact message and the fix.

Start Here: Doctor and Fix

Run flint doctor first. It checks this machine and the current Flint. It gives one next command for each problem. It starts no agent. It exits 0 when each check passes, else 1. Doctor and Fix explains each check.

flint doctor
flint doctor -p <dir>

Repair a Failure with flint fix

When flint sync, flint create, flint git sync, flint shard install, flint setup, or flint tinderbox sync fails, Flint writes one failure record. The output then ends with Or: flint fix. Run flint fix to start a repair session for the newest record. The session runs in the Computer Flint (see The Computer Flint). With no Computer Flint, it runs in the failed Flint, and flint fix prints Later: flint setup computer. An input refusal (a wrong command line) and a stop (Ctrl-C) write no record.

flint fix --list
flint fix
flint fix <n>

A failure record is one JSON file in <NUU home>/flint/failures/. The default NUU home is ~/.nuucognition. Only you can read the file (mode 600). Flint keeps the newest 20 records. Doctor and Fix > The Failure Record lists the fields of a record.

The failed Flint is usually outside the working folder of the session. The agent CLI can then ask your permission for each edit there. That is expected.

Report a Problem to NUU Cognition

To report a problem to NUU Cognition, run flint feedback. It builds a report and opens a new issue of NUU-Cognition/flint-public after you agree. --with-failure adds only the facts of the newest failure record: the command words, the exit code, the error code, the Flint version, and the time. The removal of secrets from your text is not complete: read the report and remove each secret before you submit it. Doctor and Fix > Report a Problem to NUU Cognition explains the flags.

flint feedback --bug "<what went wrong>" --with-failure

“This folder is not inside a Flint.”

✘ This folder is not inside a Flint.
  Next: flint list

Many commands find the Flint from the working folder. Any folder inside the Flint works. Move into a Flint, or pass the Flint path where the command supports it (usually -p <dir> or --path <dir>). flint list shows the Flints of this machine. flint doctor -p <dir> gives <dir> is not inside a Flint. with the same next command.

“Unknown command”

✘ Unknown command: heal
  Next: flint --help

Old names such as flint heal, flint repair, flint agent, flint code, and flint export print this, with exit 1. A name that is near a command also gets an Or: line, for example Or: flint cd for flint code. Run flint --help to see the current commands. Use flint orbh for agent sessions.

In place of flint heal and flint repair, run flint doctor to find the problem, or flint fix to repair the last failure. The repair commands of each subsystem stay: flint obsidian repair, flint shard reinstall, and flint tinderbox heal.

Some removed commands print the command that replaces them instead. For example, flint obsidian reset prints flint obsidian repair --replace --reset-settings --dry-run, and flint open --no-plugin prints its replacement. Obsidian in Other Commands lists the removed Obsidian commands.

Sync Blocks

Sync explains the sync model. flint sync never asks the shard registry. It never touches the origin of the Flint.

A Held Rebase Blocks the Sync

A halted Git sync has unresolved conflicts.

When flint git sync halts on a conflict, Git holds a rebase in the Flint. flint sync then writes nothing into the tree. It stops with exit 2 and lists the conflicted files. The step Resolve Flint shows Git needs recovery. The message stays until the Git sync continues or stops, also after you resolved the files. Resolve the conflicted files, then continue the Git sync:

flint git sync --continue

To take one side of each file whole during the halt, run flint git resolve --local [paths...] or flint git resolve --remote [paths...]. The paths are relative to the working folder. To stop the held rebase and restore the branch, run flint git sync --abort.

A Git Merge, Cherry-Pick, or Revert Is in Progress

A Git merge is in progress.

Finish it with git <kind> --continue, or stop it with git <kind> --abort. Then run flint sync again.

The Flint File Does Not Parse

A flint.toml that does not parse blocks the run with exit 2. A flint.json that does not parse stops it with exit 1. See A State File Does Not Parse.

The Shard Has No Lock Line

The shard <alias> has no lock line. Run flint shard install.

The spec in flint.toml is new or changed. flint sync does not move the lock. Run the named command:

flint shard install
flint sync

Local History Is Ahead of Origin

Local history is N commits ahead of origin. Run flint git sync.

This is a notice, not a failure. Run flint git sync to send the commits.

Retired Sync Flags

The flags --no-git and --no-update are retired. Each prints one line that names the new command, and the sync runs.

Git Sync Halts and Conflicts

flint git sync checkpoints the local work, fetches, integrates, runs the local sync, checkpoints the writes of the sync, and pushes.

A Conflict Halts Before the Local Sync

Resolve the conflict markers in the affected files. Then continue:

flint git sync --continue

A bare re-run of flint git sync also continues. The local sync runs after the conflict is resolved, before the push. To restore the branch instead, run flint git sync --abort.

A Held Merge, Cherry-Pick, or Revert Refuses the Sync

flint git sync and flint git merge refuse with exit 2 and change nothing. Finish the held operation with git <kind> --continue first. Then run the command again.

The Remote History Was Rewritten

When no local-only commits exist, the sync realigns automatically. When local-only commits exist, the sync halts and asks for --replay to carry them over the new history:

flint git sync --replay

Force One Side

--force-remote takes the remote as truth: it keeps local work that merges and discards what does not. --force-local takes the local side as truth: overlapping changes resolve in favour of local commits. --continue with --replay, --force-remote, or --force-local is refused.

The Push Runs Even When the Local Sync Fails

When the local sync fails, the push still sends the integrated history as it is. The writes of the failed local sync stay uncommitted. When origin moved during that sync, the push is rejected, and the next flint git sync sends it.

The Run Lock Is Blocked

One Git run at a time holds the run lock of the repository. When the wait for the lock times out (60 seconds), flint git sync and flint git merge report blocked with exit 2. Wait for the other run to finish, then run the command again.

Shard Install Refusals and Stale Builds

An Install Refuses Before the First Write

flint shard install runs every refusal of the root shard before the first write, also before the dependency installs. It refuses when the alias or the shorthand is taken, the shard is already present, a present dependency is outside its range, or the id or the hash differs from the registry. Nothing is written. Fix the named conflict, then run the install again. To install under another key, pass --alias <alias>.

When the shard registry does not answer, an install from Git goes on. It prints The registry did not answer (<reason>): the local record says unchecked, and flint shard install asks again. The answer goes into the local record of this machine (.flint/shards.json), never into the lock. An install from a path never asks the registry. A no-argument install with no registry answer prints The registry did not answer. The answers were not recorded.

A Registry Record Has No Shard Id

Most registry records have versions now. A few older records still have no shard id. An install by package name of one of them fails:

✘ the registry record nuucognition/chrome-use has no shard id (an older CLI registered it), so it has no versions.
  Next: flint shard install --from-git NUU-Cognition/shard-chrome-use

An older CLI made the registry record of that package. The record has no shard id, so it has no versions to install. Nothing is written. Install the shard from its Git repository with the command that the output names:

flint shard install --from-git NUU-Cognition/shard-chrome-use

The Next: line names the repository of the package that failed.

The Build Is Stale

⚠ The build of <ref> is stale: its source changed after the build. Next: flint shard build <ref>

The source moved past its build. flint shard start prints this notice on stderr and loads the build anyway. <ref> is the package name, or the alias when the alias differs from the name. flint sync builds a stale build of a source again. To rebuild by hand, run:

flint shard build <ref>

Shards Are Installed but the Flint Still Feels Broken

The Flint declaration and the local shard state have drifted apart. Inspect one shard, then repair:

flint shard list --sources
flint shard status <ref>
flint shard reinstall <shorthand>
flint sync

For all installed shards, make the lock match the specs first, then make the files match the lock:

flint shard install
flint sync

flint shard update moves the lock of each shard to the highest version inside the range of its spec. On a Flint with the 0.6.0 shard records, every shard write is refused with the next command flint migrate run. Shards explains the shard model.

Modules and Env Files

Modules, Crons, and DMs explains the module model. flint doctor checks the row Modules: each record needs a usable build, each plan must run, and the plan must be empty. A plan with changes gives Next: flint sync.

A Legacy [modules.<id>] Table

[modules.crons] is a legacy table of a built-in module. Move the keys of [modules.crons] to Modules/Crons.settings.toml by hand, without the key enabled. Each table [modules.crons.schedules.<name>] becomes [schedules.<name>]. Then remove the table. When the table has enabled = false, do not install the module.
→ flint module install @nuucognition/module/crons

A table [modules.<id>] with no source key is a declaration of the 0.7.0 pre-releases. Sync never reads it as a record, and no migration moves it. Follow the step by hand: move its keys, without enabled, to the named settings file, remove the table, then run the named install and flint sync. When the table has enabled = false, do not install the module. See the [modules] table in Configuration.

flint module install and flint module uninstall refuse a name that has a legacy table:

✘ flint.toml holds the legacy table [modules.crons] of a built-in module. Nothing was written.

Remove the table by hand first. Then run the command again.

A Module Name Is Refused

✘ "My Module" is not a module name: use lowercase letters, digits, and dashes. Nothing was written.
  Next: flint module install <input> --name <other>

A record name is kebab-case. A verb of flint module (list, status, install, and the rest) cannot be a name either:

✘ list is a verb of flint module, so it cannot be the name of a module. Nothing was written.
  Next: flint module install <input> --name <other>

Pick another name with --name.

The Plan of a Module Failed

<the error>. Sync does not reconcile the module <name>.

The plan fails on a non-zero exit, the time limit of 30 s, or output that does not parse. The failure fails only the row of that module. Sync never reads a failure as a removal: the objects of the module stay as they are. Fix the module, then run flint sync.

The Settings File Does Not Parse

The settings file of the module <name> does not parse: <reason>. Sync does not reconcile the module.
  Next: Correct <path>.

Correct the settings file (Modules/<Name>.settings.toml) at the named cause. Then run flint sync.

A Secret Is Missing

The module <name> needs the secret <NAME>, and no env file of this Flint sets it.
  Next: Set <NAME> in flint.env.local (this machine) or flint.env (the Flint).

Set the value in flint.env.local (this machine) or flint.env (the Flint). A value in flint.env.local wins. Never commit these files. See Configuration > Env Files.

An Env Line Is Not Loaded

A line that does not parse is not loaded:

flint.env line <n>: <reason>. The line is not loaded.

Correct the line. A name that starts with FLINT_ is refused:

flint.env line <n> sets <NAME>. Only Flint sets a FLINT_* value, so the value is not loaded.

Rename it: only Flint sets a FLINT_* value. When flint.env.example names a value that no env file sets, sync and flint module status show one notice:

flint.env.example names <A, B>, and no env file of this Flint sets them.

A notice changes no exit code. Set the missing values, or remove their names from flint.env.example.

A Schedule Has No Owner

A schedule with no owner fires on no machine. flint module crons list and the sync report name the fix. Run it on the machine that must own the schedule:

flint module crons own <name>

It writes the machine slug of this machine into the settings file. Then run flint sync on the owner machine.

A Missing Name or Git Author

The Git Author Is Missing

flint create refuses before any write when Git cannot commit on this machine:

Git has no author name (user.name) and no author email (user.email) on this machine. The first commit of the Flint needs a name and an email. flint setup sets them. Nothing was written.

Run flint setup. It shows the Git author and asks the email when Git has none. To create with no Git repository instead, pass --no-git.

The Machine Has No Name

flint setup sets your Name in its first step. flint config name "<Name>" changes your Name only. flint whoami shows your Name, this machine, its org, and the NUU account. With no Name, artifact creation leaves authors out.

No Network During Setup

Flint setup needs internet access. Connect to the internet, then run flint setup again.

Setup checks the network before the first step. With no network it stops with exit 1. It asks nothing and writes nothing. Connect to the internet, then run flint setup again.

A later step that needs the network skips with a Later: line instead of failing the run. The terminal font skips with the warning No network: setup did not install the terminal font. and Later: flint setup font. The Guide step skips with Later: flint setup guide. The agent default step skips the profile pull with Later: flint orbh profiles update.

The Terminal Font Is Missing

The Obsidian terminal uses the font JetBrainsMono Nerd Font. With no font, the terminal shows no Nerd Font glyphs in the Orbh titles. Step 3 of flint setup installs a missing font. When the install fails, setup goes on. It warns The terminal font JetBrainsMono Nerd Font is not installed. <reason> and names Later: flint setup font.

flint doctor fails the row Terminal font and prints the install command. Install the font with one of these commands:

flint setup font
brew install --cask font-jetbrains-mono-nerd-font   # macOS with Homebrew

flint setup font uses Homebrew on a Mac that has it. Else it downloads the release zip of Nerd Fonts and moves the font files into the font folder of your account. With no network, it stops with The font install needs internet access. Connect to the internet, then run flint setup font again.

A State File Does Not Parse

A JSON state file that does not parse stops the command. Examples are flint.json, .flint/local.json, .flint/shards.json, tinderbox.json, the roster, and the Obsidian records. A Git merge that left conflict markers is a common cause. The message names the file, the line, the column, and the cause. Then it gives the next step:

✘ flint.json is not valid JSON at line 14, column 1. The file has Git merge conflict markers (<<<<<<<, =======, >>>>>>>). Resolve the merge conflict in flint.json: keep the correct lines and remove the marker lines. Then run the command again.
  Next: git -C '<Flint>' diff -- flint.json
  Or:   flint fix

With no conflict markers, the step says Correct the JSON at line <line> of <file>, or restore the file from Git. Correct the file at the named line, or restore it from Git. Then run the command again. The Next: command shows the change since the last commit. It shows only for a file that Git tracks. With --json, the code is json-file-invalid, and the envelope holds the path, the file, the line, and the column.

A flint.toml that does not parse blocks flint sync with exit 2. The message is flint.toml cannot be parsed. with the text of the TOML parser, which shows the line of the error. The next step is Correct flint.toml. Then run flint sync. flint doctor then fails the Lock row and marks the rows that need the file Not checked.

flint git sync checks flint.json and flint.toml before its checkpoint. A file that does not parse stops the run with exit 2 before any commit or push. The message names the file, the line, and the column, and ends with The sync changed nothing. For a TOML file, the code is toml-file-invalid.

A Flint at 0.6.0 Needs flint migrate run

A Flint that a 0.6.x CLI made is at the Flint Version 0.6.0. A write command of the 0.7.0 CLI refuses it and changes nothing:

✘ This Flint is at the Flint Version 0.6.0. This CLI needs 0.7.0. flint sync did not run.
  Next: flint migrate run
  Or:   flint migrate run --dry-run
  Or:   flint fix

Look at the plan first, then run it:

flint migrate run --dry-run
flint migrate run
flint sync

flint migrate run rewrites the 0.6.0 shard lists of flint.toml (installed, dev-remote, dev-local) into one record per shard under [shards]. Each machine also runs the local steps once for each Flint, for example the conversion of the legacy Obsidian payload (see A Legacy Git Payload). When the local state of this machine is behind, the refusal starts with The local state of this Flint on this machine is at the Flint Version <version>. The next command is the same. flint sync --migrate runs the pending steps before the sync.

“Flint <version> is available”

Once a day, a background check asks npm for the newest release of the Flint CLI. At the end of a command that exits 0, Flint then prints one notice on stderr:

Flint 0.7.1 is available (this machine has 0.7.0). Next: flint update

This is a notice, not a failure. Run flint update to install the release. A Flint CLI built from a checkout says This flint is a build of a checkout: update the checkout, then build it. in place of the Next: command. The same check names newer Orbh profiles: Newer Orbh profiles are available. Next: flint orbh profiles update.

The notice shows at most once a day. It never shows in a pipe, with --json, in CI, or in an Orbh session. To turn the check off on this machine, run flint config set update-check off. To turn it off for one shell, set FLINT_NO_UPDATE_CHECK=1. flint update --check checks now and installs nothing.

The Computer Flint Claim

One machine has one Computer Flint. When another Flint tries to take the role, the claim refuses:

One machine has one Computer Flint. The Flint <id> at <path> holds the claim (<claim path>, made <time>). Convert that Flint to another type first. If that Flint is gone, run: flint setup computer --show-claim

flint setup computer --show-claim shows the claim of this machine: held or stale. A stale claim names a Flint that is gone:

No Flint at <path> and no Flint of the roster has the id <id>. If that Flint is gone, release the claim: flint setup computer --release-stale-claim

Release it with the named command. It prints The stale claim is released. A claim that a Computer Flint holds is never released.

The word computer is reserved for the Computer Flint. flint open computer resolves to it from any folder. No other Flint can take the word as its name. Do not move the Computer Flint by hand: the claim then names a missing folder and goes stale. Move it with flint move computer "<new path>" so the claim follows.

Agent Profile Errors

Orbh Has Only Its Built-In Profiles

No <path>: Orbh has only its built-in profiles.

The Orbh home has no synced default.json. flint doctor fails this row with the next command:

flint orbh profiles update

This pulls the latest shared default profiles into the Orbh home. It leaves your own profiles file untouched. When newer profiles are available later, Flint prints Newer Orbh profiles are available. Next: flint orbh profiles update.

No Target of the Default Target List Is Available

flint orbh i, flint orbh launch, and flint orbh request with no target start the first available target of the default target list. When no target is available, the command refuses. It names the install command or the login command of the first target:

✘ No target of the default target list is available.
  claude/o55h skipped: claude is not installed
  codex/a6h skipped: codex is not installed
  Next: npm install -g @anthropic-ai/claude-code

An explicit target never falls back to another target:

✘ The target claude/o55h is not available: claude is not installed. An explicit target does not fall back.
  Next: npm install -g @anthropic-ai/claude-code

flint doctor fails the Agent row when no target can launch:

No target of the default target list (<list>) is available. <reasons>

The next command is the next command of the first target, for example its install command or its login command. With no such command, it is flint fix. To see the layers of the list and the target that a launch selects, run:

flint orbh profiles default   # The default target list, its layer, and the state of each target
flint orbh runtimes           # The runtimes, their CLIs, and whether each one is installed
flint orbh profiles           # The profiles of each runtime

Make sure the target runtime is installed. For example, Claude sessions need Claude Code installed, and Codex sessions need Codex installed. Agent Sessions > The Default Target List lists each skip reason and its next command. For any agent workflow, also check that the Flint has the shards and the references that the agent expects.

A Flint Does Not Appear in flint list

Register it:

flint register /path/to/flint

If the roster row is stale, register the Flint again. A registered Flint takes the name and type of flint.toml again. Then inspect the status:

flint list --status

A Declared Codebase Reference Is Still Unfulfilled

Declare it with a path, or fulfil an existing declaration:

flint reference codebase "Flint" /path/to/flint

flint fulfill codebase "Flint" /path/to/flint
flint reference list

flint fulfill supports codebase resources only. flint sync fulfils Flint references from the roster.

A Flint Reference Will Not Resolve

Make sure the target Flint is registered locally:

flint list
flint register /path/to/target-flint

Then run:

flint sync

A reference to a Flint that is not on this machine is one report row, not a failure.

A Flint Bundle Does Not Sync

Sync finds the producer Flint through the roster. Register the producer Flint first, then run flint sync. When the producer has no bundle, sync reports:

The producer Flint has no bundle <name>.

Make the bundle in the producer Flint. To drop the reference instead, run flint reference remove <name>.

A Workspace Repository Is Declared but Missing on Disk

Check status and then restore it:

flint workspace list
flint workspace update "<name>"

flint workspace update pulls the latest changes, or clones the repository when it is missing.

A Source Repository Is Declared but Missing on Disk

Check status and refresh it:

flint source repo list
flint source repo update "<name>"

flint source repo update re-fetches the repository: it deletes and re-clones it.

Obsidian

Using Obsidian explains the model. This part lists the common cases.

Look at the State First

flint obsidian status            # the payload, the vault, the plugin, and the next command; writes nothing
flint obsidian status --check    # also finds an old plugin; exits 2 on an error or a warning

The last line is Next: <command>. Run that command. Each Obsidian write has a dry run: flint sync --dry-run, flint obsidian update --dry-run, and flint obsidian repair --dry-run. A dry run writes nothing and sends nothing to Obsidian. The dry run of flint obsidian update --to <release> fetches nothing. When it cannot read the manifest of the release, the plan ends with · fetch needed, and the exit code is 0. Its next step is the same command with no --dry-run.

The Payload Is Not Installed

✘ The Obsidian payload is not installed. Next: flint sync.

When the network is down, the fetch fails with Could not fetch Obsidian payload <release> (<reason>). Check the network, then run the named command again. The Flint works for CLI work in the meantime.

A Release File Changed Outside Flint

Blocked: 1 release file changed outside Flint.
    plugins/terminal/main.js
  No files were changed.

Something changed a file that Flint owns, for example an edit of a plugin bundle. flint sync and flint obsidian update stop and change nothing. Look at the plan, then replace the file:

flint obsidian repair --replace --dry-run
flint obsidian repair --replace

The replace saves your version in a backup first. To look at your version later, copy the backup into an empty folder:

flint obsidian backups list
flint obsidian backups restore <id> --to /tmp/my-version

The Install Waits: The Vault Is Open

Obsidian payload <release> pending: the vault is open. Flint writes .obsidian/ only while the vault is closed. The pending install is not a failure. Close the vault in Obsidian, then run:

flint open "<name>"

flint open installs the pending payload first, then launches Obsidian.

Obsidian Runs and Does Not Know the Folder

Obsidian runs, and its vault registry has no entry for "<name>". A link cannot open a folder that Obsidian does not know.
Obsidian: open "<name>" once from Obsidian: Manage vaults, then Open folder as vault, then choose <path>

flint open launches a vault by a link only when the vault registry of Obsidian has an entry for the folder. Flint writes that entry only while no Obsidian process runs. This is not a failure, and the exit code is 0. Do the named step once in Obsidian. Or quit Obsidian, then run flint open "<name>" again.

flint open computer Refuses

✘ This machine has no Computer Flint. Next: flint setup computer. The word computer names the Computer Flint of this machine. Make it with the named command.

The Plugins of a New Vault Are Off

With the trust setting auto (the default), flint open asks Obsidian to trust a Flint that passes the trust check. Else Obsidian asks once for the new vault. Click Trust author and enable plugins. flint obsidian status shows the setting and the result of the check on the line Trust. For example, the check fails when the setting is ask, when a plugin file of the payload changed, or when .obsidian/plugins holds another plugin. Using Obsidian > Open a Flint explains the check.

When the plugin of the vault does not answer and the trust check failed, flint open prints a notice with the reason, for example Flint did not ask Obsidian to trust "<name>": a plugin file of the payload changed outside Flint. Next: flint obsidian status.

When status says open · NUU Flint plugin not running, it warns NUU Flint is not running in "<name>". The next step is If Obsidian asks, click "Trust author and enable plugins"; else enable "NUU Flint" in Settings → Community plugins.

An Old, Unprotected Plugin

"<name>" runs an old, unprotected NUU Flint plugin (0.6.x). The vault was open during the upgrade to 0.7.0, so it still runs the old plugin. Close the vault in Obsidian, then run flint open "<name>". The vault then opens with the new plugin.

A Legacy Git Payload

.obsidian in <name> is a legacy Git payload. In a Flint of 0.6.x, .obsidian/ is a Git clone of the payload source. Close the vault first, then convert it:

flint migrate run --dry-run
flint migrate run

The next command is flint migrate run, or flint obsidian repair after a recorded conversion. flint obsidian update and flint obsidian repair convert a legacy payload too, with a closed vault.

When the vault is open and Flint cannot reload it, or when the fetch of the release fails, the conversion waits. Flint can reload an open vault when its NUU Flint plugin runs and the command runs in a terminal outside that vault. After a failed fetch, the text is The conversion of <name> waits: Obsidian payload <release> could not be fetched: <reason>. Close the vault, then run flint open "<name>" or flint sync.

When a file at a release path differs from the old payload, the conversion changes nothing and names flint obsidian repair --replace --dry-run.

A Settings File Is Not Valid JSON

<file> is not valid JSON. Settings migration <id> did not run. The release files are installed, and one settings migration waits. Reset the file to its initial settings, after a backup:

flint obsidian repair --reset-settings --file <file> --dry-run
flint obsidian repair --reset-settings --file <file>

Start Again from the Release

flint obsidian reset is removed. It prints flint obsidian repair --replace --reset-settings --dry-run. To replace each changed release file and each settings file, run:

flint obsidian repair --replace --reset-settings --dry-run
flint obsidian repair --replace --reset-settings

Flint saves each file in a backup first. A full restore gives the files back: flint obsidian backups restore <id> (the vault must be closed).

A Restore or a Reset Is Blocked

A restore and flint obsidian repair --reset-settings never write through a link. An unknown object on the path blocks the run, and no file changes:

The object is a file or a link on the folder chain of the path, or a folder or another object at the path itself. <restore command> is your restore command with every argument.

A Move or a Delete Refuses an Open Vault

"<name>" is open in Obsidian. Close it, then run the command again from a terminal outside Obsidian.

flint move, flint rename, and flint delete refuse an open vault. The refusal names the command to run again in a Next: line. A move under an open vault leaves a ghost folder. Close the vault first. A terminal tab of the vault closes with the vault, so run the command in a terminal outside Obsidian.

flint tinderbox heal does not refuse. It keeps the folder of a member whose vault is open, and it makes the other repairs. A warning says "<name>" is open in Obsidian. Close the vault, then run flint tinderbox heal again from a terminal outside Obsidian.

When Obsidian runs during a move, the change of the vault registry waits: Obsidian runs, so the vault registry change waits. Quit Obsidian, then run flint obsidian vaults repair --yes.

When you moved or deleted a Flint folder by hand, the vault registry entry names a missing folder. Quit Obsidian, then run flint obsidian vaults repair (the preview) and flint obsidian vaults repair --yes.

A waiting vault registry change is kept in <NUU home>/flint/obsidian/registry/pending.json. An entry of that file with a wrong form does not run, and Flint keeps it. flint obsidian vaults repair, flint sync, and flint open then warn: <path> holds an entry that is not a vault registry change, so no command runs it: <entry>. Next: Remove the entry from <path>, then run: flint obsidian vaults repair.

Obsidian Is Off on This Machine

✘ Obsidian is off on this machine (<config path>). Next: flint config set obsidian on.

A Tinderbox Command Refuses the Box

A write command of flint tinderbox runs one write gate before its first effect. The gate refuses a box that a newer CLI shaped, or a box with a malformed record, and nothing is written. A tinderbox.json that does not parse gives the file, the line, the column, and the cause, as A State File Does Not Parse shows. A record that parses and is malformed names its file with the next step Fix tinderbox.json. Then run flint tinderbox check. A newer record gives tinderbox.json states version <version>, and this CLI writes <version>. and names the update of the CLI. A .tinderbox folder that is a link is refused too. Update the CLI or fix the record, then run the command again. See Using Tinderbox.

flint tinderbox git sync Stopped in the Middle

The journal .tinderbox/git-sync-state.json keeps the run. Look at it first. It writes nothing:

flint tinderbox git status

Then continue the run. flint tinderbox git resume continues each member that the last sync did not finish:

flint tinderbox git resume

A member that holds a rebase is blocked. Resolve its files, then run flint tinderbox git resolve <member>.