Adopted environment upgrade mutated the source gateway state database

Summary

During an OpenClaw release-validation run, an OCM-adopted disposable environment was upgraded to an exact beta runtime. The candidate did not remain confined to the adopted environment: it migrated the original source gateway's shared state database from schema 7 to schema 8.

The source gateway could no longer start on its original checkout after the validation attempt and required recovery. The OCM checkpoint available for rollback had been created after the migration, so it did not contain a recent schema-7 copy.

Environment

• Host: Windows 11 with Ubuntu WSL
• OCM: 0.2.32
• Source OpenClaw: 2026.8.1 at f329a9489f32e6472ded5437be971609229c9451
• Candidate: v2026.8.1-beta.2 at 8f382a202ff1e15833394b481615dcdda99b04d7
• Source: a real gateway state directory
• Target: an adopted OCM environment with a distinct environment name, state directory, and port

No credentials or user-specific paths are included here.

Sequence

1. Inspect and import the real gateway into a disposable environment using the documented ocm adopt inspect, ocm adopt plan, and ocm adopt import flow.
2. Install and verify the exact candidate runtime.
3. The adopted environment had defaultRuntime=null, so set its runtime explicitly before continuing.
4. Run the candidate upgrade dry-run, upgrade, and start against the adopted environment.
5. Observe that the isolated candidate reports the exact beta version but fails readiness.
6. Inspect the source gateway after the failed validation run.

Expected behavior

• All candidate migrations and writes stay within the adopted environment's state directory.
• The source gateway's configuration, databases, and schema metadata remain byte-for-byte unchanged.
• A pre-upgrade checkpoint exists before any candidate migration and can restore the adopted copy independently of the source.

Actual behavior

• The isolated candidate failed startup three consecutive times with:

  Gateway failed to start: Cannot read properties of undefined (reading 'values')

• The original source gateway's state database was migrated from schema 7 to schema 8.

• Its schema metadata recorded app_version=2026.8.1-beta.2, even though the source gateway had not been intentionally upgraded.

• The source checkout supported schema 7 and could no longer restart against the migrated database.

• The available OCM checkpoint was created after the migration and therefore did not provide a recent schema-7 recovery copy.

• The exact retained path, link, or environment reference through which the candidate reached the source database has not yet been identified.

The release-facing startup failure was recorded in the shared validation ledger: https://github.com/openclaw/openclaw/issues/125626#issuecomment-5341586820

Impact

This breaks the central safety guarantee of the release-validation workflow: a tester can follow the isolated-copy path and still mutate or disable the gateway they actively use. A failed beta upgrade can therefore affect data outside the disposable environment, while the resulting checkpoint may be too late to recover the pre-migration state.

Requested safeguards

• Resolve and verify all candidate-writable paths after adopt/import and before upgrade.
• Fail closed if any config include, symlink, workspace reference, database path, or resolved state path escapes the adopted environment or aliases the source gateway.
• Create and verify a pre-migration checkpoint before starting the candidate runtime.
• Ensure the checkpoint itself is independent of candidate-writable state.
• Add an integration test that upgrades an adopted copy and asserts that the source state tree and database schema hash remain unchanged.
• Surface the resolved source and target state roots in redacted diagnostic output so an isolation failure can be traced without exposing credentials.

The source gateway has since been recovered, but the isolation escape remains unexplained.

No source files or tests are named. Start by tracing the documented ocm adopt inspect, ocm adopt plan, and ocm adopt import flow, then follow state-path and checkpoint resolution during upgrade. Reproduce the adopted-copy validation and add coverage showing that the source state tree and schema hash remain unchanged while a pre-migration checkpoint is available.