DeepSeek Harness Data Backup: 2026 Migration Checklist

Session loss after an upgrade → back up four separate layers: rebuildable environment, session state, workspace assets, and protected credentials.

A copied folder is not proof of recovery → restore into an isolated environment and complete one real task before signing off.

This guide is for you if you are preparing a DeepSeek Harness preview upgrade, moving a local setup to a cloud Mac, rebuilding a machine, or handing a long-running Agent workspace to another operator. If you only need to preserve source code and do not use persistent sessions, most of this process is unnecessary.

SECTION 01What DeepSeek Harness data backup must preserve

Treat the backup as an acceptance package, not as a duplicate of the entire home directory. The correct boundary has four layers:

• Rebuildable environment: installation source, DeepSeek Harness version, runtime version, package manager state, operating mode, and dependency manifest.
• Durable session state: persistent events, session metadata, task status, tool activity, approvals, and model selection.
• Workspace assets: repositories, branches, uncommitted changes, local instruction files, generated artifacts, and external dependencies.
• Sensitive credentials: API key references, provider identifiers, encrypted secret material, and the rotation record.

Do not back up only the repository. That protects source history but does not prove that a session can be reopened or that an Agent can continue from the same task state.

Do not copy every file under the application directory without classification. Source caches, temporary build output, package downloads, logs with secrets, and reinstallable binaries increase exposure while making the recovery package harder to inspect.

The main acceptance question is simple:

Can a clean environment reopen the intended session, select the correct model, execute an approved tool, and write only to the intended workspace without exposing a credential?

A successful file copy answers none of those questions by itself.

SECTION 02Which files are rebuildable and which are durable?

Start by recording how the environment was created. Save the installation source, the exact DeepSeek Harness revision or release identifier, the runtime version, the operating mode, and dependency manifests. This record lets you reconstruct the runtime instead of treating installed software as irreplaceable state.

The current DeepSeek Harness repository documentation describes a session persistence layer, a SQLite-backed store, configuration surfaces, and separate runtime components. Those implementation details should be checked against the version you actually operate, because a repository layout is not a universal migration contract. (github.com)

Keep these items in the rebuild record:

• Installation command or package source.
• Version, commit, or release identifier.
• Runtime and package manager versions.
• Provider mode and model identifier.
• Enabled plugins, Skills, MCP tools, or equivalent extensions.
• Project instruction files that affect Agent behavior.
• A dependency lockfile or reproducible dependency manifest.
• A short note explaining which paths are intentionally excluded.

Usually rebuildable items include package caches, temporary compilation output, downloaded archives, and software that can be installed from a trusted source. They should not be mixed with session state unless the application documentation explicitly requires them for recovery.

A useful backup manifest separates each path or artifact into three columns:

1. Required to reopen or resume.
2. Required only to reproduce the environment.
3. Excluded because it is temporary, replaceable, or sensitive.

If a file cannot be classified, do not silently include it. Mark it for manual review. Ambiguous files are where credentials and stale runtime state often enter an otherwise clean migration package.

SECTION 03Why SessionEvent records matter more than chat transcripts

A session is not necessarily just a transcript of user and assistant messages. Persistent event logs can also represent tool calls, tool results, approvals, model choices, task transitions, and other events required to replay or inspect an Agent run.

The term SessionEvent should therefore be treated as a state record, not a synonym for visible chat text. The public implementation material describes event-oriented session handling and SQLite-backed persistence, while the exact format and storage structure must be verified against the version being migrated. (github.com)

Before copying session data:

• Stop the Harness process so no new event is being written.
• If a clean stop is not possible, create a documented consistency boundary.
• Record the number of sessions included.
• Record the newest event timestamp or sequence marker.
• Confirm that the session database or event files can be read.
• Export a manifest containing session identifiers and intended owners.
• Select one session for an isolated restore test.

Do not assume that copying DSH_HOME alone will recover everything. It may contain user-level state, but it does not automatically prove that the associated repository, branch, project instructions, plugins, runtime, or provider configuration will be available on the destination Mac.

The session backup should answer these questions:

• Can the session be listed?
• Can the session be opened without an error?
• Is the last known task state visible?
• Are tool calls and approvals still represented?
• Is the selected model or provider identifier preserved?
• Does the session point to the expected workspace?
• Can the restored Agent continue without silently starting a new session?

The format version deserves special caution. The current task boundary treats the session format as pre-release and does not guarantee cross-version compatibility. That means a successful backup from the old environment is not enough. You need a restore test on the candidate version before allowing production work to continue.

Migration warning: Never overwrite the only copy of a persistent event store during an upgrade. Preserve the original package as read-only until the destination completes both file checks and a real task test.

SECTION 04Does the workspace have to move with the session?

Yes, when the session contains repository-specific reasoning, tool actions, generated files, or pending work. A session restored without its matching workspace can appear healthy while directing the Agent at the wrong repository or an empty path.

For every session, record:

• Absolute workspace path on the source Mac.
• Repository identity and remote origin.
• Current branch.
• Current commit.
• Uncommitted changes.
• Untracked files.
• Submodules or external repositories.
• Local project instructions and Skills.
• Required environment files, excluding their secret values.
• Generated artifacts that are not reproducible from source.

The destination path does not have to be identical, but the mapping must be explicit. If the old session expects /Users/operator/project and the cloud Mac uses /Users/runner/project, record the translation and verify it before enabling write access.

A safe restoration order is:

1. Restore the repository or workspace into a quarantine path.
2. Confirm the expected remote and branch.
3. Compare the recorded commit with the restored commit.
4. Review uncommitted and untracked changes.
5. Restore local instruction files only after reviewing them.
6. Open the session in read-only or non-destructive mode.
7. Grant write permission only after the workspace identity matches.

This prevents a common handoff failure: the Agent resumes correctly but edits a similarly named checkout, a stale branch, or a temporary directory.

If the workspace contains generated output, decide whether it is evidence or disposable output. A build directory may be safely recreated. A manually edited generated configuration may not be. The backup manifest should state the decision for each local-only artifact.

SECTION 05Settings, plugins, and runtime assets need separate compatibility checks

Separate configuration by ownership. A setting may belong to the user, the project, or the runtime environment, and those scopes should not be merged into one opaque archive.

Review these groups independently:

• User settings and interface preferences.
• Provider identifiers and model selection.
• Project instruction files.
• Plugin configuration.
• Skills and tool definitions.
• MCP or external service endpoints.
• Runtime environment variables.
• Dependency and package metadata.
• Shell startup files and launch scripts.

The provider identifier can usually be retained as configuration metadata. The actual API key must be handled separately. Plugin names and configuration can also be preserved, but plugin binaries and third-party assets should be reinstalled or validated from trusted sources rather than blindly copied from an old machine.

Developer preview releases require an explicit compatibility gate. The repository documentation describes multiple moving components, including the chat interface, batch engine, transport, approval layer, and storage layer. A change in one component can affect the recovery path even when the visible session interface looks unchanged. (github.com)

For each plugin or Skill, record:

• Name and version or commit.
• Installation source.
• Required runtime.
• Required permissions.
• Configuration file location.
• External services used.
• Whether it is required to open a session or only to execute a specific task.

Mark every item as one of the following:

• Reuse after validation.
• Reinstall from source.
• Recreate manually.
• Do not migrate.

The last category matters. Old scripts may contain obsolete paths, unsafe shell commands, or embedded secrets. A migration is not complete merely because every old extension loads successfully.

SECTION 06API keys belong outside the ordinary backup package

No. A normal backup package should contain credential references and access requirements, not a directly usable API key.

Separate the following items:

• Provider name.
• Account or project identifier.
• Environment variable name.
• Secret manager reference.
• Permission scope.
• Rotation owner.
• Last validation result.
• Expiration or review date, if applicable.

Use a separate authorized process to provision credentials on the destination. Transfer them through an encrypted channel, limit access to the operator who needs them, and rotate the key if it was exposed during packaging, testing, or handoff.

Search the backup before delivery. Inspect:

• Plain-text environment files.
• Shell history.
• Debug logs.
• Crash dumps.
• Exported session transcripts.
• Temporary archives.
• Editor swap files.
• Git patches.
• CI artifacts.
• Screenshots or copied command output.

The official privacy and account documentation should be reviewed alongside your internal secret-handling policy before a migration package leaves the source environment. Review the official account and privacy documents before deciding what may be retained in logs or transferred between operators. (platform.deepseek.com)

A restored environment must also prove that the key is not being passed to the wrong plugin, workspace, or shell process. Model access is only one part of the test. Secret isolation is part of acceptance.

SECTION 07A defensible cloud Mac migration follows eight controlled steps

Use a staged process. Do not combine backup, upgrade, credential provisioning, and production execution into one uncontrolled action.

First step: Freeze the source state

Stop DeepSeek Harness and related worker processes. Record the stop time, active session list, current workspace state, and the version being replaced. If the source cannot be stopped cleanly, label the backup as crash-consistent and require a stronger restore test.

Second step: Build the asset manifest

Create separate entries for environment metadata, session state, workspace assets, settings, plugins, and credentials. Include source paths only after verifying them on the actual operating mode. Do not publish a fixed directory list as if it applied to every installation.

Third step: Create an encrypted backup package

Encrypt the package at rest. Keep credentials outside the ordinary archive. Generate a checksum or equivalent integrity record for the package and store it with the migration ticket, not inside the only copy of the archive.

Fourth step: Rebuild the destination runtime

Install the runtime from the recorded source. Apply the dependency manifest. Recreate the expected user and project configuration. Install plugins from their recorded sources. Do not copy old binaries just because they are convenient.

Fifth step: Restore into quarantine

Place the session store and workspace in an isolated path. Keep the restored workspace read-only while you verify repository identity, branch, commit, and local changes. Open the session before enabling tools.

Sixth step: Provision credentials separately

Inject the required secret through the approved mechanism. Verify that the provider can be called, but do not use a destructive or irreversible task for the first test.

Seventh step: Execute an end-to-end acceptance task

Choose a reversible task, such as inspecting a file, generating a disposable report, or making a change in a test branch. Confirm that the session opens, the intended model responds, the tool executes, the workspace is correct, and approval controls still apply.

Eighth step: Record the decision

Mark each criterion as pass, conditional pass, or reject. A conditional pass requires a named remediation owner and a deadline. If the session opens but the workspace mapping is wrong, reject the migration. If the files are intact but the model call fails, reject the migration. If the real task succeeds but credentials appear in logs, reject the migration.

SECTION 08The restore decision needs both file evidence and task evidence

Use two evidence classes together.

File-level evidence should include:

• Backup manifest.
• Integrity record or checksum.
• Version and dependency record.
• Session inventory.
• Workspace mapping.
• Plugin and configuration inventory.
• Credential exclusion statement.
• Restore log.

Task-level evidence should include:

• Session opened from the restored store.
• Expected task state was visible.
• Correct model or provider was selected.
• Tool execution completed.
• Approval remained effective.
• The Agent operated in the intended workspace.
• No credential appeared in output or logs.
• The test change was reversible and cleaned up afterward.

The file test proves that the package is present and readable. The task test proves that the environment still behaves as an operational system. You need both before an upgrade, cloud Mac migration, or handoff can be accepted.

SECTION 09Backup options differ by recovery objective

Use the following comparison when deciding what belongs in the delivery package.

The safest default is the fourth option. It avoids the false confidence of an indiscriminate archive while preserving enough evidence to rebuild and verify the environment.

Before moving work to a rented machine, review the MACNOX cloud Mac options only after you have defined the restore test and required operating mode. The machine is a destination for the verification process, not a substitute for one.

SECTION 10Acceptance criteria for upgrade and handoff

Accept the environment only when all of these conditions are true:

• The runtime can be recreated from recorded sources.
• The session inventory matches the source.
• The restored SessionEvent data is readable.
• The workspace path maps to the expected repository.
• Branch and uncommitted state have been reviewed.
• Settings and plugins are classified and validated.
• No ordinary backup archive contains a usable API key.
• The model call succeeds with separately provisioned credentials.
• A tool executes under the intended approval policy.
• A reversible task completes in the correct workspace.

Reject or pause the handoff when any of these conditions occurs:

• The session opens as a blank conversation.
• The event store is present but unreadable.
• The destination points to a similarly named repository.
• A plugin loads without a recorded source or version.
• The candidate release changes the session format without a restore test.
• Credentials are found in logs, archives, or scripts.
• The Agent can write before workspace identity is confirmed.
• The operator cannot explain which files were excluded.

If your current Mac cannot provide an isolated restore window, a temporary cloud Mac can be useful for validation. In that case, keep the test workspace disposable, use a separately authorized credential, and remove the environment after evidence is captured. Review the MACNOX ordering options only if you need that temporary verification environment; a long-term heavy workload, permanent physical-interface requirement, or fixed always-on deployment may be better served by owned hardware or another infrastructure model.

The important comparison is not “old Mac versus new Mac.” It is “unverified copy versus accepted recovery.” A local machine may lack a safe quarantine window, may mix personal credentials with development files, and may force you to test the upgrade against the only production session. A temporary MACNOX cloud Mac gives you a separate place to rebuild, restore, and reject the candidate without destroying the source environment.

Before you approve the change, attach the four-layer manifest and the end-to-end task evidence to the handoff record. If the restored Agent cannot complete one real, reversible task in the correct workspace without exposing a credential, the migration is not finished.