[Bug] Session create hard-fails on a best-effort Flock freshness sync when the network is degraded

[zxch3n]

Affected area

CLI / daemon

Installation method

Built from source

Lody version or commit

lody-oss @ 48249c9, CLI 0.89.3

Operating system

macOS (arm64)

Agent or runtime

N/A — fails before any agent is started

What happened?

While this machine's outbound network was degraded, every attempt to create a session through MCP lody_session_create was refused — even though the machine was online, the target local project was already known locally, and lody_session_create_options had just returned that same project successfully from local state moments earlier.

The failure comes from a freshness confirmation sync, not from anything the create actually needs:

COMMAND_REJECTED: Flock document sync failed for <ws>:mf:<machine>
  (session.local-projects:<machine>): Streams sync failed: network_error

Path:

lody_session_create
└─ resolveLocalProjectRefOrThrow            apps/cli/src/commands/session.ts:987
   └─ syncMachineFlockDocsForRead(…, 'session.local-projects')
                                            apps/cli/src/commands/session.ts:995
      └─ syncFlockDocOrThrow(…)             apps/cli/src/lib/loro/doc.ts:947
         └─ repo.sync({ scope: 'doc' })  →  Streams → network_error

syncFlockDocOrThrow throws after an 8s timeout (LODY_LORO_SYNC_MACHINE_FLOCK_TIMEOUT_MS), and the create is rejected before its Operation is ever persisted — a subsequent lody_session_create({ operationId, resume: true }) returns OPERATION_NOT_FOUND.

Every input the create needs (machineId, projectId, prompt) is local. The remote round trip only confirms that the local Flock replica is fresh.

This also contradicts the documented intent one layer down. apps/cli/AGENTS.md says of dispatch:

Cloud confirmation … is AWAITED … but NEVER throws — the durable pointer plus the SQLite Operation own delivery. Do not reintroduce a hard-fail Streams ack on the dispatch write.

The dispatch write is protected; this pre-dispatch read is not. The human CLI has an escape hatch for the equivalent read commands (--offline); the MCP surface has none.

What did you expect?

With the machine online and the project locally known, session creation should proceed from the local replica and treat the Flock sync as best-effort (the same policy the dispatch write already uses), or expose an explicit offline equivalent on the MCP surface.

How can we reproduce it?

1. Register a local project and connect the daemon to a workspace.
2. Degrade outbound network so Streams sync round trips exceed ~8s (packet loss or throttling is enough; a full disconnect also reproduces).
3. Call lody_session_create_options — it succeeds and returns the machine, agent config, and local project.
4. Call lody_session_create with exactly those ids.
5. It fails with COMMAND_REJECTED: Flock document sync failed … Streams sync failed: network_error.

How often does it happen?

Every time

Relevant log output

2026-09-04T13:06:38.391Z [DEBUG] [W:<ws>] Machine Flock doc sync was not confirmed before continuing (machine=<machine> reason=<reason>): Streams sync failed: network_error
2026-09-04T13:07:22.162Z [DEBUG] [W:<ws>] Machine Flock doc sync was not confirmed before continuing (machine=<machine> reason=<reason>): Streams sync failed: network_error

For contrast, the same log window shows ordinary outbound request failures unrelated to Lody's own backend, confirming the trigger is local connectivity rather than a service outage:

2026-09-04T13:09:23.632Z [DEBUG] [pr-poller] Network error polling <repo>; retrying after the attempt floor: fetch failed

Additional context

The impact is disproportionate to the cause: a transient network problem makes session creation impossible, which is exactly the condition local-first execution is meant to survive.

Suggested fix, smallest first:

1. Resolve the local project from the local Flock replica and downgrade syncMachineFlockDocsForRead on the create path to best-effort (log, do not throw), matching confirmDispatchSyncedBestEffort.
2. If some caller genuinely needs the freshness guarantee, make it opt-in rather than the default, and give the MCP surface an explicit offline equivalent of the CLI's --offline.

Two related problems observed in the same window are filed separately: a self-sustaining Streams reconnect loop, and error-classification/retry-advice defects.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.