Symptom → A remote Mac opens websites, but DeepSeek Harness still fails on API calls, Git, dependencies, or MCP tools.

Fastest fix → Run separate acceptance tests for each outbound dependency and record DNS, TLS, proxy identity, credentials, timeout, and recovery evidence. Do not approve the environment if any critical path depends on a temporary manual proxy or exposes a secret in logs.

This runbook is for:

  • Technical owners writing network requirements into a remote Mac purchase or rental.
  • Operators separating DeepSeek API, Git, package manager, and MCP failures.
  • Developers working behind enterprise proxies, internal DNS, certificate inspection, or outbound allowlists.

Start with the acceptance boundary

DeepSeek Harness is not accepted merely because its interface loads. The acceptance target is a repeatable outbound execution path under the same account and process type that will run the real work.

DeepSeek’s official integration material describes model calls, workspace access, command execution, and external tool connections as part of the broader coding-agent workflow. The exact destinations still depend on the selected provider, repository host, package manager, MCP Server, and project configuration. Do not create a universal hostname list from another project. Build the list from the actual Harness configuration and dependency lockfiles.

Your acceptance record should answer five questions for every scenario:

  1. What external or local service was tested?
  2. Which identity and process performed the test?
  3. What evidence proves each network stage completed?
  4. Where did the failure occur if the test failed?
  5. What action is required before delivery?

A browser screenshot is weak evidence. It proves that one interactive application reached one page through one path. It does not prove that a background Harness process can resolve the same name, inherit the same proxy, read the same credential, or complete the same protocol exchange.

The hidden limits you need to expose

  • Interactive and unattended processes may differ. A proxy variable exported in a terminal may not exist inside a launch agent, scheduled task, or service process.
  • Browser access does not prove Git access. Git may use HTTPS credentials, an SSH key, a credential helper, a different host, or a different network policy.
  • A warm cache hides broken delivery. A project can appear healthy because packages already exist locally. A clean rebuild may fail immediately.
  • MCP has multiple network segments. The Harness-to-server connection can work while the MCP process cannot reach its external data source.
  • Certificate trust is process-sensitive. The operating system, Node.js runtime, package manager, and enterprise proxy may not use identical trust stores.
  • Retry behavior can create side effects. A disconnected tool call may be repeated after the upstream service already completed it.

Do not disable TLS verification to make a test pass. Node.js explicitly warns that NODE_TLS_REJECT_UNAUTHORIZED=0 makes HTTPS insecure, and its proxy support is intended for authorized deployment paths rather than policy evasion. Read the runtime guidance on proxy and TLS environment variables.

Build one evidence record before testing

Use a separate record for each remote Mac, account, and Harness process. Do not mix results from your local computer with results from the delivered machine.

Capture these fields:

  • Test date and time.
  • Remote Mac identifier or delivery reference.
  • macOS and Node.js versions.
  • Harness version and configuration revision.
  • Execution identity.
  • Interactive shell, background agent, scheduled task, or service context.
  • Proxy mode: direct, enterprise proxy, or approved gateway.
  • DNS result and resolver path.
  • TLS result and certificate validation outcome.
  • Credential source, recorded only as a name or reference.
  • HTTP, Git, package manager, or MCP result.
  • Failure stage and proposed corrective action.
  • Whether the test was repeated after restart.

Never include a real API key, personal access token, private key, customer repository contents, full authorization header, or sensitive proxy password in the evidence package. Replace those values with REDACTED and record the secret reference in your approved secret-management system.

For DeepSeek API tests, use a small request with non-sensitive text. The official API example uses a bearer token and a chat completion endpoint. The important evidence is not the generated answer alone. Record the resolved address, TLS validation, HTTP status, response headers that are safe to retain, request identifier if available, and the exact failure stage. Review the official chat completion request format.

Verify the model API path from DNS to response

What if the remote Mac opens a website but the DeepSeek API does not connect?

Treat this as a layered test, not an application mystery. A successful webpage may use a browser proxy, cached DNS, a different certificate policy, or an authenticated browser session. Harness may run with none of those conditions.

Test object

Test the smallest non-sensitive model request through the exact endpoint, provider mode, environment variable set, and process type that DeepSeek Harness will use.

The test should cover:

  1. DNS resolution for the configured API host.
  2. TCP connection through the approved route.
  3. TLS handshake and certificate validation.
  4. Credential loading without printing the credential.
  5. HTTP request transmission.
  6. Upstream response parsing.
  7. Timeout and cancellation behavior.

The DeepSeek API documentation currently shows model-specific request parameters and supports tool-related request structures. Do not hard-code an old model name merely because an older Harness template uses it. Confirm the model identifier and endpoint against the target configuration at delivery time. Check the official chat completion API reference.

Success evidence

A passing record should show:

  • The target name resolved from the remote Mac.
  • TLS validation succeeded without bypass flags.
  • The intended execution identity loaded a credential reference.
  • The API returned an expected success status.
  • The response was parsed by the same client path used by Harness.
  • No secret or sensitive prompt entered the logs.
  • A restart test produced the same result.

Failure separation

  • DNS failure: The name cannot be resolved, resolves incorrectly, or resolves only inside the browser.
  • TLS failure: The route exists, but the certificate chain, hostname, trust policy, or proxy inspection certificate is not accepted.
  • Credential failure: The request reaches the upstream service but is rejected for missing, invalid, expired, or unauthorized credentials.
  • Upstream service failure: DNS, TLS, and authentication succeed, but the provider returns a service-side error.
  • Local egress failure: The process cannot reach the approved route because of firewall, proxy, allowlist, or process inheritance rules.

Reject the test if the only working method is copying a key into a shell history line, exporting a proxy manually before every run, or using a TLS bypass option.

Prove private Git operations without exposing repository data

A browser login to a code-hosting page is not a Git acceptance test. Git can use a separate HTTPS credential helper, SSH key, SSO authorization, known-hosts file, proxy route, and background-process environment.

Test object

Use a disposable test repository or an approved empty repository. Verify the minimum operations required by Harness:

  1. Discover the remote URL.
  2. Authenticate through the selected HTTPS or SSH path.
  3. Clone or fetch a controlled reference.
  4. Read the expected branch or tag reference.
  5. Make a harmless local change.
  6. Push only to a controlled test branch if delivery requires push access.
  7. Remove the test checkout after evidence is captured.

Do not clone a customer repository merely to demonstrate connectivity. Do not paste a private key into the acceptance ticket. Record only the protocol type, remote host category, authentication mechanism, and result.

HTTPS and SSH are separate paths. Official Git documentation notes that HTTPS clone URLs work behind many firewalls and proxies, while SSH requires an authorized key and may be affected by port restrictions. SSH over an HTTPS port can be an option in some environments, but it still requires the correct hostname, host-key verification, and enterprise approval. Compare the documented HTTPS and SSH remote paths.

Success evidence

Keep:

  • Sanitized remote URL pattern.
  • fetch or clone result.
  • Reference or commit identifier from the disposable repository.
  • Authentication method.
  • Push result if required.
  • Host-key or certificate validation result.
  • Execution identity and process type.

Failure separation

  • Repository discovery failure: The URL is wrong, the repository is unavailable, or DNS cannot resolve the host.
  • Transport failure: HTTPS proxy, SSH port, firewall, or TLS path blocks the connection.
  • Identity failure: The credential exists but lacks repository or organization authorization.
  • Workspace failure: Git succeeds, but Harness cannot read the checkout because of path permissions or process identity.
  • Policy failure: The network works, but pushing is correctly blocked by branch protection or organization policy.

Reject the environment if only the browser can authenticate, if the background process cannot access the credential helper, or if the test requires placing a long-lived token in a plaintext file without an approved control. Review the documented credential options and token handling rules.

Rebuild dependencies instead of trusting the cache

A first install proves less than a clean rebuild. Existing node_modules, package-manager caches, and previously exported proxy variables can hide an incomplete delivery path.

Test object

Test three states:

  • Harness installation or update.
  • Plugin and MCP package installation.
  • Target project dependency installation from its lockfile.

For npm projects, use the project’s declared lockfile process. npm ci is intended for automated environments, requires an existing lockfile, removes an existing node_modules tree, and fails when the lockfile and package manifest do not match. Check the official npm ci behavior.

Run the sequence under the actual unattended identity:

  1. Record the Node.js and package-manager versions.
  2. Record the configured registry and approved proxy mode.
  3. Remove or isolate the dependency directory.
  4. Clear only the approved test cache, not shared production caches.
  5. Run the clean installation.
  6. Run the project’s dependency verification or test command.
  7. Restart the remote Mac or relevant service.
  8. Repeat the installation or a controlled update check.

npm honors proxy environment variables when they are present, and its documented default fetch timeout is 300,000 milliseconds. That value is a package-manager behavior, not a promise that every dependency source will respond within that period. Record the actual timeout configuration and the stage where the request stopped. Review npm’s configuration reference.

Success evidence

  • Clean installation completed from the approved route.
  • Lockfile remained unchanged unless the workflow explicitly allows updates.
  • Dependencies were rebuilt after cache isolation.
  • Plugin installation succeeded under the background identity.
  • Restarted Harness could load the same packages.
  • No dependency credential or proxy password appeared in output.

Reject conditions

Reject delivery when:

  • The first run passes only because a cache is already populated.
  • A developer must export proxy variables manually for each terminal.
  • The service account sees a different registry or certificate trust path.
  • The installation requires disabling TLS validation.
  • The lockfile cannot reproduce the installed tree.

Trace MCP across three independent segments

How do you separate an MCP Server network failure from a configuration failure?

Use one read-only tool with harmless input. Do not begin with a write-capable tool, a production data source, or a tool that triggers billing or deployment.

MCP supports standard stdio and Streamable HTTP transports. With stdio, the client launches the server as a subprocess. With Streamable HTTP, the server operates as an independent process and uses HTTP requests to exchange JSON-RPC messages. These are different acceptance paths. A local process starting successfully does not prove that its external data source is reachable. Review the transport requirements.

Test object

Verify the following chain:

  1. Harness discovers the configured MCP server.
  2. The client completes initialization and capability negotiation.
  3. The client receives the expected tool list.
  4. A read-only tool call reaches the server.
  5. The MCP server reaches its upstream data source.
  6. The result returns to Harness and is parsed.
  7. Cancellation or disconnect behavior is recorded.

The protocol defines tools/list for discovery and tools/call for invocation. An error returned inside a tool result is different from a protocol-level failure, so keep those categories separate in the evidence.

Failure map

  • Harness to MCP: Server command, path, permissions, local port, transport, or initialization problem.
  • MCP to upstream: DNS, TLS, proxy, firewall, or external API problem inside the MCP process.
  • Credential authorization: The upstream is reachable but rejects the MCP credential or scope.
  • Tool-level result: The protocol works, but the selected tool returns an application error.
  • Cancellation: The client disconnects or cancels, but the server continues work or produces a duplicate side effect.

For Streamable HTTP, a network disconnect should not automatically be interpreted as cancellation. The protocol recommends explicit cancellation when the client wants the request stopped. Test this behavior with a read-only operation and record whether the task stops, retries, waits, or returns a duplicate result.

Make proxy, DNS, and certificate behavior reproducible

How should you accept an AI Agent in an enterprise proxy environment?

Run the test twice: once interactively and once from the persistent process that will execute DeepSeek Harness. The second result controls acceptance.

Document:

  • Which account owns the proxy configuration.
  • Which process inherits it.
  • Whether uppercase and lowercase proxy variables are both handled.
  • Which internal names bypass the proxy.
  • Whether localhost and loopback addresses bypass the proxy.
  • Which certificate trust store validates inspected HTTPS traffic.
  • Whether the package manager and Node.js use the same trust behavior.
  • What happens when the proxy is unavailable.

Node.js supports HTTP_PROXY, HTTPS_PROXY, and NO_PROXY when environment proxy support is enabled. Its documentation also describes matching forms for exact hosts, domain suffixes, ports, and address ranges. Use the organization’s approved rules. Do not invent a broad bypass list. Review the documented proxy matching behavior.

macOS evaluates certificates through trust policies, including hostname matching for SSL. Enterprise certificate deployment should follow the organization’s managed configuration process. Do not tell operators to mark an unknown certificate as always trusted or to bypass hostname validation. Review Apple’s certificate trust policy guidance.

A common delivery defect looks like this:

  • Terminal test succeeds.
  • Harness started from the terminal succeeds.
  • Harness started after login or restart fails.
  • The missing value is a proxy variable, certificate path, credential helper, or working directory.

Fix the process environment, not the symptom. A temporary export is a test clue, not a delivery solution.

Test interruption recovery before signing delivery

A network path that works only while uninterrupted is not automatically suitable for unattended development work.

Use a controlled read-only or idempotent task. Then interrupt the network briefly at an approved control point. Observe:

  • Does the task stop immediately?
  • Does Harness retry?
  • Does the MCP server continue running?
  • Does the client reconnect?
  • Is the original request status known?
  • Can the task be safely resumed?
  • Could a repeated call create a duplicate side effect?

Avoid destructive tests. Never simulate an outage by deleting customer data or interrupting an operation that writes to production.

The delivery package should include:

  • Test timestamp.
  • Target service or protocol type.
  • Execution account.
  • Process type.
  • Sanitized command or operation name.
  • DNS, TLS, proxy, and authentication result.
  • Failure stage, if any.
  • Retry or cancellation behavior.
  • Recovery action.
  • Result after restart.

Your acceptance rule should be:

  • All required core paths pass.
  • Sensitive values do not enter logs.
  • The same paths can be reproduced after restart.
  • Any failure has a documented owner and corrective action.
  • No critical path depends on a person opening a terminal first.

Compare acceptance outcomes before approval

Use this table to make the sign-off decision. “Conditional” means the path may be usable for a limited test, but it is not ready for unattended delivery.

Acceptance option API Git Dependencies MCP Background proxy and restart Decision
Browser-only check Page loads Not tested Not tested Not tested Not tested Reject
Interactive shell pass Passes in terminal May pass May use warm cache May start locally Unknown Conditional
Clean process pass Passes under target identity Fetch and controlled push pass Rebuild passes Discovery and read-only call pass Verified after restart Accept
Manual proxy or TLS bypass Possibly passes Unclear Unsafe or unstable Unclear Not maintainable Reject
Partial scenario pass One or more paths fail Evidence incomplete Evidence incomplete Evidence incomplete Recovery unknown Hold delivery

Decide whether the current setup is fit for use

The current setup may be a local Mac, an existing cloud host, a corporate workstation, or a general-purpose virtual machine. Its common weaknesses are easy to miss: browser-only validation, hidden credentials, inconsistent proxy inheritance, warm dependency caches, and no restart evidence.

A remote Mac supplied through MACCOME is a better fit when you need a clean, repeatable Mac execution environment for temporary DeepSeek Harness testing, repository validation, or controlled migration work. You can review available remote Mac options through the MACCOME remote Mac catalog and select a region only after confirming that your organization permits the required outbound destinations.

Do not rent if the workload requires permanent high-volume execution, dedicated physical interfaces, hardware-attached security devices, or guaranteed long-term network policy control. In those cases, owning and managing the hardware may be more appropriate.

For short-term acceptance, migration, or provider testing, start with the remote Mac ordering options, then complete this network evidence matrix before moving customer repositories or production credentials. If a region-specific test is required, compare the Silicon Valley remote Mac option only after your network owner confirms the acceptable route.

The safest handover is not “DeepSeek Harness opened successfully.” It is a signed record showing that the model API, Git, clean dependency rebuild, MCP tool path, enterprise proxy, DNS, TLS trust, interruption recovery, and restart test all passed under the intended execution identity.