The browser opens, but nobody can prove the agent can work safely or recover after a restart.

Fastest fix: run a seven-gate acceptance test and sign only when every critical result is reproducible.

Last updated

Last updated August 18, 2026. Technical behavior was checked against the official DeepSeek Harness repository, its Web UI guide, its architecture documentation, and the public MACCOME cloud Mac delivery page.

Who should use this runbook

Technical buyers can turn a vague delivery promise into signable acceptance items. Developers can verify that the remote environment completes real tasks instead of showing a demo screen. Operations teams can assign responsibility for permissions, logs, restarts, updates, backups, and rollback.

A cloud Mac that opens DeepSeek Harness is not automatically accepted.

DeepSeek Harness is still described as a developer preview, and its official repository warns that compatibility-breaking changes may occur. Its default Web UI command starts a local service at http://127.0.0.1:3080, but that fact alone says nothing about remote access control, workspace isolation, credentials, or recovery after a machine restart. (github.com)

Start with an evidence-first acceptance sheet

Do not begin by clicking through the interface. Begin by creating one evidence folder for the delivery. Store terminal output, screenshots, configuration exports, test inputs, successful results, and failure signals in the same location.

Record these fields before changing anything:

Acceptance field What to capture Pass condition
Machine identity Hardware model, chip family, memory, storage, hostname, public address The delivered machine matches the order and can be identified later
Operating system Exact macOS release and build The value comes from the machine, not the product name
Harness source Package command, repository URL, commit, tag, or release reference Another operator can install or identify the same source
Runtime Node.js, package manager, shell, and relevant dependency versions Commands return values that are saved with the test record
Launch method The exact command, profile, working directory, and service wrapper The receiving team can start the same profile
Model route Provider, model identifier, endpoint type, and credential owner A fixed test request returns a recorded success signal
Access path SSH, VNC, browser console, tunnel, or other approved route The route and account responsibility are documented

The official README shows both the npm-based launch path and the source-build path. It also states that the Web UI is served at 127.0.0.1:3080 by default. Capture the actual command used in your delivery instead of assuming that the default was retained. (github.com)

A useful evidence rule is simple:

  • No command output, no version claim.
  • No controlled test, no permission claim.
  • No restart record, no persistence claim.
  • No named owner, no operational handover.

Decision conditions for the first gate

  • If the provider gives you exact commands and reproducible output, continue to functional tests.
  • If the provider gives only a machine label such as “Apple Silicon cloud Mac,” request the missing runtime evidence before acceptance.
  • If the source is a moving developer-preview branch with no recorded commit or package reference, accept only as a time-limited evaluation.
  • If the delivered profile differs from the tested profile, repeat the tests. Do not transfer results between profiles.

Verify access and identity boundaries before testing the agent

Remote access is a separate control plane from DeepSeek Harness. SSH or VNC permissions determine who can enter the Mac. Harness approval settings determine what the agent can request or execute after it has entered the workspace.

Treat these as different acceptance items.

Check the following:

  1. Sign in with the named delivery account.
  2. Confirm whether the account has administrator rights.
  3. Test the approved remote access methods from a clean client.
  4. Confirm whether the Web UI is bound to localhost, a private interface, or an exposed address.
  5. Test an unlisted account or unauthorised route.
  6. Rotate or replace temporary credentials before handover.
  7. Record who owns the Apple ID, API credential, SSH key, and recovery contact.

The acceptance evidence should include a redacted account list, the access method, the permission level, and the credential replacement procedure. Never place private keys or API tokens in the handover package.

A common delivery failure looks like this: the buyer receives a working VNC screen, but the original setup account remains active, the API key belongs to the provider, and nobody knows whether a failed agent command should be approved by the developer or the operations team. The screen is usable. The delivery is not operationally owned.

Test the real workspace instead of trusting the configured path

The Web UI guide states that the process uses its invoking directory as the default filesystem location, while a fresh Web UI has no selected workspace until one is added. It also describes model configuration, workspace selection, command execution, file editing, delegation, and approval prompts. These are the behaviors you must test in the delivered environment. (github.com)

Create a disposable repository with four deliberate boundaries:

  • A file the agent should be able to read.
  • A file the agent may modify.
  • A file that should remain read-only.
  • A directory outside the declared project workspace.

Then run a fixed sequence:

  1. Ask the agent to list the repository structure.
  2. Ask it to read the allowed file.
  3. Ask it to make a harmless, reviewable change.
  4. Ask it to attempt a write to the read-only path.
  5. Ask it to inspect the outside directory.
  6. Ask it to run a harmless command that prints the current directory.
  7. Review the approval prompt and the resulting session record.

Capture the exact path the agent could see. Record whether the operation succeeded, failed, or waited for approval. A field labelled “workspace configured” is not enough because filesystem, subprocess, terminal, and sandbox providers may be composed separately.

The official architecture documentation describes the filesystem provider, subprocess execution, sandbox backend, guarded tool pipeline, and profile composition as distinct pieces. That means a workspace claim must be validated through real reads, writes, commands, and denied operations. (github.com)

Workspace acceptance conditions

  • Pass: allowed reads and controlled writes work; denied paths fail or require the expected approval; the result is saved.
  • Conditional pass: the workspace works, but a required tool is disabled or requires manual approval for every operation.
  • Fail: the agent can access a broader path than the contract allows, or the receiving team cannot identify the active workspace.
  • Fail: a restart changes the selected workspace without a documented reason.

Run the model and tool chain with one fixed benchmark

Do not accept a delivery because a model appears in a settings screen. Verify the complete chain from credential to response, tool call, approval, and result write-back.

Use a fixed benchmark that is small enough to repeat and rich enough to expose failure points:

Inspect the test repository, identify the entry file, create a short report in the approved output directory, and show the command result.

Save the input exactly. Then record:

Test stage Required action Evidence to retain Acceptance signal
Credential load Configure the approved model credential Redacted settings view or command output The credential is accepted without exposing its value
Minimal response Send a short deterministic prompt Input and response A valid response arrives from the intended route
Tool discovery Ask the agent to inspect the repository Tool event or UI trace The expected filesystem tool is available
Command approval Request a harmless command Approval screen and result The command is blocked, approved, or executed according to policy
File write-back Create the report in the allowed directory File hash or diff The output exists at the expected path
Failure handling Use an invalid path or rejected command Error message and session record The failure is visible and does not look like success

DeepSeek Harness describes the model adapter, tool registry, session log, agent loop, and approval policy as plugin-based components. Its architecture also describes durable events for model messages and tool calls. Therefore, “the model answered once” is a weaker test than “the model, tools, approval path, and write-back all produced traceable results.” (github.com)

If the model call fails, separate these causes:

  • Missing or expired credential.
  • Wrong model route or endpoint.
  • Network failure.
  • Plugin or profile mismatch.
  • Approval policy rejection.
  • Workspace or command failure after the model response.

Do not label all of them “DeepSeek Harness unavailable.” The corrective owner may be different for each failure.

Separate the Mac delivery from the Harness delivery

A cloud Mac provider may deliver the machine, public address, remote access, storage, and billing cycle. DeepSeek Harness may be installed later by your team. These are two delivery layers with different evidence.

The public MACCOME cloud Mac order page presents machine configurations, delivery nodes, billing cycles, remote access options, and storage choices. Verify the actual instance against the order record instead of relying on a sales message or machine nickname.

The following sample is a reference for checking a delivery page, not a promise that every order has the same availability:

Delivery item Public page example What you still need to verify
Standard machine Mac mini with an Apple Silicon configuration Actual allocated hardware and installed macOS
Memory and storage Multiple configuration choices may be offered Actual memory, storage health, and free capacity
Access methods Remote access options may be listed Which methods are enabled for your account
Billing Several rental cycles may be listed Contract term, renewal, cancellation, and data deletion rules
Delivery region Multiple locations may be selectable Current availability and measured client latency

Do not convert public configuration information into a performance guarantee. A larger memory tier does not prove that the delivered Harness profile, model route, or workspace policy is correct.

If your use case needs a location-specific route, compare the available MACCOME cloud Mac regions before purchase. Your acceptance record should contain a fresh measurement from the actual client network.

Make restart and persistence a controlled experiment

Persistence is one of the most commonly overstated parts of a cloud Mac delivery. The official architecture documentation says the session log is the source of model-visible context and that durable session events support replay, resume, transcripts, and persistence. That does not prove that the entire remote environment will return in the same state after a machine restart. (github.com)

Run this sequence with non-sensitive data:

  1. Create a named test session.
  2. Select the intended workspace.
  3. Save a harmless configuration change.
  4. Run one model request.
  5. Execute one approved tool call.
  6. Record the active profile and launch command.
  7. Perform a controlled restart with the responsible operator present.
  8. Reconnect through the documented remote access path.
  9. Check the session list, workspace selection, model configuration, plugin set, and logs.
  10. Repeat the benchmark task and compare the results.

Classify every item as:

  • Automatically restored.
  • Restored after selecting the profile or workspace.
  • Requires manual configuration.
  • Not restored.
  • Not tested.

Never replace “not tested” with “should persist.” Also avoid promising a recovery duration unless the same machine, profile, storage path, and access route have been measured.

A useful restart record contains the start time, shutdown method, reconnect method, restored state, missing state, error output, and named owner for the next action. The record should make clear whether the failure belongs to macOS startup, the service wrapper, the Harness home directory, the model credential, or the remote access layer.

Build the maintenance and rollback handover

Continuous Agent work needs more than a login. It needs a stop button and a known rebuild boundary.

Request these operational materials:

  • Log locations and log collection commands.
  • A basic health check for the Mac.
  • A process or service status check for DeepSeek Harness.
  • The approved restart command.
  • The owner of version updates.
  • The owner of package and plugin changes.
  • Backup scope for sessions, profiles, workspaces, and configuration.
  • Credential rotation steps.
  • Data deletion steps at lease end.
  • The environment rebuild boundary.
  • The rollback entry point.
  • A list of actions that require provider support.

Provider-level service documentation may describe remote access, public addressing, support, and lease-end erasure behavior. Match those claims to your account and contract. They do not replace your own test of Harness sessions, workspace state, or plugin restoration.

A good handover package excludes plaintext secrets. Give the receiving team a secret owner, rotation procedure, and validation command instead. If a token must be injected manually after every restart, write that limitation down. It may be acceptable for a short evaluation, but it is not the same as unattended operation.

Use three sign-off outcomes

Do not force every delivery into “pass” or “fail.” Use three conclusions.

Accept

Use accept when:

  • Environment identity is captured from the delivered machine.
  • The Harness source and profile are reproducible.
  • Remote accounts and credential ownership are clear.
  • Workspace and command boundaries match the contract.
  • Model calls, tools, approvals, and write-back pass the fixed benchmark.
  • Restart behavior is recorded.
  • Logs and recovery instructions are accessible.
  • The handover package contains no plaintext keys.

Accept with a deadline

Use accept with a deadline when the environment can support limited evaluation but has a documented non-critical gap. Examples include a missing convenience plugin, manual workspace selection after restart, or incomplete log packaging.

Write the owner, exact corrective action, evidence required, and deadline. Do not allow an undefined “we will improve this later” item into production Agent work.

Reject or return for remediation

Return the delivery when:

  • The delivered hardware or operating system cannot be identified.
  • The model route cannot complete a fixed test.
  • The agent can modify files outside the agreed boundary.
  • Credentials belong to an unknown party.
  • Restart behavior is unknown for a task that requires persistent execution.
  • The provider cannot explain how to collect logs or rebuild the environment.
  • Critical results cannot be reproduced by the receiving team.

A working demo is not a substitute for evidence.

Why the current setup may lose to a rented Mac

Your current setup may be a developer laptop, a shared workstation, or an improvised virtual machine. Those options often introduce three operational weaknesses: the machine may sleep or be unavailable, permissions may depend on one person’s account, and the environment may be difficult to reproduce after an update or failure. They also make it harder to separate an Agent workspace from personal files and ad hoc credentials.

A rented physical Mac from MACCOME can be a better fit when you need a dedicated remote environment, a defined access path, a selectable delivery node, and a short evaluation window without buying hardware first. These capabilities still need to be checked against the acceptance sheet above; they should not be treated as automatic proof of Harness recovery or task isolation.

If you need long-term heavy workloads with stable utilization, hardware ownership may still be more economical. If you need physical peripherals, local debugging, or full control over the operating system lifecycle, rent less and retain the machine yourself. For temporary DeepSeek Harness testing, remote Agent work, or a project that has not yet settled on its final memory and storage needs, renting MACCOME cloud Mac capacity lets you validate the workflow before committing to hardware.

Before ordering, submit your expected concurrency, workspace isolation rules, access methods, and rental period. Ask MACCOME to map those requirements to the same acceptance sheet. That keeps the decision tied to a deliverable environment rather than an unverified configuration promise.