Troubleshooting & limits

Fix connection and sync issues, and understand the current implementation's limits.

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.

NextIntroduction

Search documentation

Search the guides, tutorials, and command reference.

↑ ↓ to navigate↵ to open · esc to close