Start with local status
cor status
cor conflicts
cor remote list
These commands are safe to use while a worker is running. Status reads local state without contacting current, so it tells you what the workspace knows, not whether the server is reachable at this moment.
Connection problems
“No remote configured”
Run cor remote add YOUR_SERVER:8787 once, or start
cor work in a terminal for guided setup. Confirm you are
inside the right project; use --root PATH if needed.
“Waiting for current” or a connection error
Check that current is running, the saved address is reachable, and the
expected port is open. Use cor remote list to inspect the
address. A configured worker retries automatically. On the server, its
startup output shows the listening address and data folder.
SSH key rejected or encrypted key unavailable
On current, authorize the matching public key with
cor keys add FILE.pub. Select the private key with
--identity PATH, or load it into your agent with
ssh-add PATH. cor whoami shows the
authenticated fingerprint.
Unknown or changed SSH host key
Compare the host fingerprint with current's startup output. Confirm a new
host interactively, or pass the verified value with
--host-key SHA256:.... A changed host is refused; only replace
the saved pin after independently verifying a deliberate host-key rotation.
Port 8787 is already in use
Choose another port, for example
cor current --bind '[::]:8788', then update clients with
the matching address. Keep the same data directory to preserve the
repository identity.
IPv6 loopback is unavailable
For a local test, use
cor current --bind '127.0.0.1:8787' and connect to
ssh://127.0.0.1:8787. The no-argument server also has an IPv4
fallback when IPv6 is unavailable.
The workspace belongs to another current node
Verify the address and server data directory. Repository identity is deliberately pinned to prevent accidental attachment to a different project. Use a new workspace for a different repository. Preserve existing client state and files; do not delete them to bypass the check.
Files aren’t syncing
I saved, but my teammate has not seen it yet
Allow one second of quiet, or up to five seconds of intentional batching
during continuous saves. Large-file hashing and transfer take additional
time. Check both workers, the server connection, ignore rules, and
cor conflicts. If current is offline, changes remain local
until an exchange succeeds.
A file is excluded unexpectedly
Check the root and nested .gitignore files plus root
.laplaceignore. An excluded directory must be re-included
before a child can be re-included. Git metadata, node_modules,
and Corotation internals always stay excluded.
A package was rejected, but one of its files did not collide
That is the whole-package rule. Every path in the rejected batch stays blocked, including paths that could have succeeded alone. Inspect the full package and follow the repair workflow.
The workspace or data directory is already locked
Stop the other owning work, sync, or
resolve process before running another writer. Stop current
before a manual baseline. Do not delete a lock file while its
owning process is running.
There is a symlink, special file, or bad path error
Corotation does not synchronize symlinks or special files. Exclude them explicitly. Use portable UTF-8 filenames and consistent spelling; case-only renames and Unicode normalization aliases across filesystems are not supported.
Build and install problems
“corotation: command not found” after installation
Run the PATH command printed by the installer, or open a new terminal after
allowing shell configuration. By default the executable is in
~/.local/bin. Check your chosen --bin-dir if you
used one.
A compiler wrapper prevents the build
The Just recipes clear RUSTC_WRAPPER. If using Cargo directly,
run env RUSTC_WRAPPER= cargo build --release --locked. If
SQLite compilation fails, check the native C toolchain as described in
the prerequisites.
Storage and recovery
Storage keeps growing
Historical chunks, receipts, baselines, orphan uploads, and local recovery copies are currently retained. Recovery/conflict copies may contain full files. There is no garbage collector yet; never manually delete chunks referenced by current or a retained baseline.
Current rolled back after restoring a backup
A client whose received sequence is ahead of the restored authority refuses to reopen normally, rather than silently accepting lost history. Preserve both the client workspace and restored server data. Review the independent backup and unsynchronized work before deciding how to recover; there is no automatic history reconciliation command.
An export failed partway through
Inspect the error and the partial destination. Exports refuse existing output directories, so retry into a new folder after fixing the connection or storage problem. Verify the recovered files before using them to replace working content.
Current limits
This is an early, working implementation with tests for concurrency, corrupted data, interrupted recovery, network exchange, native watching, batching, and CLI setup. It has not undergone prolonged production use or exhaustive power-loss testing.
- No garbage collection. Storage grows with retained history and recovery data.
- No branches, text merge engine, or multi-authority failover. Baselines provide recoverable checkpoints.
- One trusted team. SSH authenticates each key and encrypts transport. All authorized keys have project access; there are no per-path roles or encryption at rest.
- macOS tested. Linux and Windows builds and filesystem behavior still need validation.
- Local durable storage required. Network filesystems and concurrent external edits to the storage directory are unsupported.
- Package bounds. At most 16 MiB of metadata and 100,000 paths. Oversized packages fail as a unit and are not silently split.
- Working-directory installation is not atomic. Readers may see an update in progress even though server acceptance is atomic.
- Corruption is detected on reads and transfers. There is no background scrub or automatic repair.
- Future formats may change. Preserve independent backups before upgrading.
Use independent backups for valuable work, and keep the current node and each client’s private state intact when diagnosing a problem.
SSH approval on every command
Upgrade current and the client, then run cor login once. Corotation enrolls a separate device key and remembers it outside the project. Future commands and reconnects use that key without contacting your password manager. If it was revoked or lost, use cor login --renew.