DeepSeek Harness node-pty Upgrade: Remote Mac Retest Plan

The confirmed change is narrow. DeepSeek Harness updated its terminal dependency to a node-pty 1.2 beta release to improve platform compatibility. It does not identify every affected macOS version, every shell behavior, or any guarantee about long-running task stability. Treat the release as a new runtime surface that needs regression testing.

node-pty creates pseudoterminal-backed processes. Its project documentation describes support for macOS, Linux, and Windows, and shows that terminal data, input, resizing, and process events are all part of the exposed behavior.

That matters because a terminal task has several separate paths:

1. The model decides to run a command.
2. DeepSeek Harness sends the command to Bash.
3. The PTY accepts input and starts the process.
4. Output moves from the child process to the session.
5. The interface renders the output.
6. Cancellation reaches the process group.
7. A reconnect decides whether you see the same session or only a new view.

A node-pty upgrade can affect the PTY path. It does not automatically repair model wait time, browser transport, session persistence, shell startup files, filesystem contention, or process supervision.

Warning: Do not record “the command eventually completed” as a passing result. A useful terminal regression also checks input echo, continuous output, exit status, cancellation, and the real child-process state.

The upstream project is still changing through beta releases. Its release history lists macOS-related fixes such as closing a kqueue file descriptor in v1.2.0-beta.14, a macOS /dev/ptmx leak fix in beta.10, and pixel-size support for resize() in beta.9. These changes show why the exact locked dependency matters. They do not prove that rc.7 fixes your specific workload.

Not by itself. You need to separate three delay sources before drawing a conclusion.

PTY or shell delay appears when a command has started but input or output behaves incorrectly. Examples include missing input echo, output arriving in bursts, a prompt that never returns, or a process that ignores a control signal.

Transport delay appears when the remote Mac is working but the browser view stops receiving updates. The process may continue even though the interface looks frozen.

Model delay appears before or between tool calls. Bash may be healthy while the agent is still reasoning, waiting for a tool result, or deciding what to do next.

Use the same command set on the previous version and on rc.7. Keep the shell, working directory, environment variables, Node runtime, and workspace unchanged. Do not compare a fresh installation with a heavily used session. That changes too many variables.

A suitable first pass includes:

printf 'echo-start\n'
for i in 1 2 3 4 5; do printf 'chunk-%s\n' "$i"; sleep 1; done
printf 'echo-end\n'
printf 'exit-status-check\n'; exit 7

This gives you several observable points:

• Whether input is echoed correctly.
• Whether output arrives progressively instead of only at the end.
• Whether the session stays controllable during output.
• Whether the final status records 7 instead of a generic failure.
• Whether the process exits without leaving a shell behind.

Do not use one successful command to claim that long Bash work is stable. A single run can miss buffering, race conditions, network interruption, or cleanup failures.

The Bash Reference Manual is useful when you need to distinguish shell behavior from terminal behavior. An input-reading problem may come from shell mode or startup configuration rather than from the PTY dependency itself.

Use the following table as your rollout tool. It keeps the decision tied to evidence instead of the presence of a dependency change.

The key distinction is between continue testing and expand usage. A candidate can be worth testing without being suitable for broader deployment.

Build tasks expose more than simple command execution. They produce bursts of output, spawn child processes, write files, and often run long enough for a disconnect or cancellation to occur.

Start with a bounded command. Then repeat with a real representative build.

Recommended sequence:

1. Run a short command that produces output every second.
2. Run a command that produces a larger output stream.
3. Run the smallest real build that exercises your toolchain.
4. Cancel during active output.
5. Check the exit state and child processes.
6. Repeat after leaving the session idle for a short period.
7. Compare the final workspace against the previous version.

Record where the failure occurs:

• No command start.
• Command starts but input echo is missing.
• Output starts and then pauses.
• Interface pauses while the process continues.
• Cancel request is visible but the process remains.
• Parent exits while a child process continues.
• Build completes but the session reports failure.
• Session reports success while expected files are missing.

For a long output test, use a command that produces known checkpoints:

for i in $(seq 1 20); do
  printf 'checkpoint-%02d\n' "$i"
  sleep 1
done

The exact count is not a stability threshold. It is only a way to see whether output progression stops at a repeatable point. If output freezes at different points, suspect transport or scheduling. If it freezes at the same operation, inspect the command, shell, and PTY path together.

The node-pty documentation describes terminal input and output handling, including flow-control-related behavior. That capability is relevant when large output is involved, but its presence in upstream documentation does not prove that DeepSeek Harness uses the same configuration in your deployment.

Experience rule: A build that finishes after the browser reconnects is not automatically a successful recovery. Verify the process tree, exit state, generated files, and session log separately.

Prioritize commands that rely on terminal behavior, not every command in your repository.

Interactive Bash commands

Test commands that require input after startup:

read -r value
printf 'received:%s\n' "$value"

Pass criteria:

• The prompt appears.
• Your input is visible or otherwise confirmed.
• The command receives the value.
• The shell returns to a usable prompt.
• The session records completion.

This directly covers the common concern that a node-pty change might remove Bash input lag. It can show improvement in your environment, but it cannot prove a universal fix.

Commands with control signals

Run a process that remains active:

trap 'printf "term-caught\n"; exit 143' TERM
while true; do printf 'running\n'; sleep 1; done

Send cancellation through the actual DeepSeek Harness control. Then inspect whether:

• The terminal reports cancellation.
• The parent process exits.
• The child process exits.
• The workspace lock is released.
• A later command can start normally.

If the interface says “cancelled” but the process remains, classify that as a failure even if the screen looks normal.

Interactive programs

Do not create a catalog of every terminal feature. Choose only programs your real tasks use. Good candidates are a command with an interactive prompt, a program that reacts to arrow keys or control characters, and a tool that changes terminal dimensions.

Check:

• Initial rows and columns.
• Resize behavior.
• Input control.
• Screen redraw.
• Exit with a normal command.
• Exit with cancellation.

The upstream release history includes a resize-related change for pixel-size support in beta.9. That makes resize behavior worth checking when your remote interface or terminal emulator uses pixel dimensions. It does not mean every application will exercise that path.

When a test fails, save the smallest reproduction. Include the command, shell, working directory, runtime version, harness version, node-pty version, terminal dimensions, and whether the failure occurred locally or through the remote interface.

A remote terminal disconnect has at least two states:

• The interface or network connection is gone.
• The PTY and its child process are still running, stopped, or terminated.

These states are independent. A browser tab closing does not prove that the process stopped. A reconnect does not prove that the process is resumable.

Run this test with a controlled long command:

mkdir -p /tmp/dsh-reconnect-test
date > /tmp/dsh-reconnect-test/start.txt
for i in $(seq 1 30); do
  printf 'remote-checkpoint-%02d\n' "$i" >> /tmp/dsh-reconnect-test/output.txt
  sleep 1
done
date > /tmp/dsh-reconnect-test/end.txt

Then:

1. Start the command through the remote Mac session.
2. Confirm that output is advancing.
3. Disconnect the browser or network path.
4. Wait for a defined test interval.
5. Reconnect to the same workspace and session.
6. Check whether new output is visible.
7. Inspect whether end.txt exists.
8. Check the actual process state.
9. Attempt a new command in the same session.
10. Record whether the task was resumed, merely observed, or lost.

Use the background-task acceptance guide as the next operational layer if your workflow depends on unattended work. The terminal test tells you what happened to one process. Acceptance testing should also verify logs, workspace state, restart behavior, and operator visibility.

If you are testing a hosted Mac, keep delivery variables separate from harness variables. Confirm the machine, shell, permissions, runtime, workspace, and access path before treating a terminal result as a software-only result. The same acceptance record can be reused across different remote Mac environments without treating the hosting environment as proof that rc.7 is stable.

Do not promise task recovery unless you have tested it. Reconnection can restore a view without restoring input control. It can also show buffered output while the underlying process has already failed.

A node-pty dependency change does not automatically require you to rewrite every remote Mac setting. Start with a controlled comparison.

Keep these values fixed:

• Shell path.
• Login versus non-login shell mode.
• Working directory.
• Environment variables.
• Node runtime.
• File permissions.
• Workspace mount or volume.
• Remote access method.
• Terminal dimensions.
• Session persistence settings.

Change only the DeepSeek Harness version and dependency lockfile. If the upgrade changes the installation path or native module resolution, document that separately.

The node-pty project notes that macOS builds may require Xcode when compiling from source. That matters if the remote Mac cannot use a matching prebuilt native module and falls back to local compilation. Check the install log. A successful package install is not enough if the runtime loads a different native binary than expected.

Also check permissions. Upstream documentation warns that processes launched from node-pty run with the same permission level as the parent process. A remote service account with different access to files, shells, or build tools can produce a terminal symptom that looks like a PTY regression.

Run a small set of representative tasks. Do not invent a universal safe task count. Any concurrency number or resource claim must come from your own remote Mac measurements.

Give each task:

• A unique workspace marker.
• A unique output file.
• A unique session label.
• A command with visible checkpoints.
• A cancellation path.

Then check:

• Output does not appear in another session.
• Cancelling one task does not cancel another.
• Each task writes only to its own workspace.
• Each task reports its own exit status.
• A failed task does not block later tasks.
• Reconnects return to the correct session.

A simple marker can be enough:

printf 'workspace=%s\n' "$PWD"
printf 'session=%s\n' "${TASK_MARKER:-unset}"

If output is mixed, stop the rollout. Terminal line interleaving is not merely a cosmetic problem when commands can write to the wrong workspace or receive the wrong cancellation signal.

The upstream project also states that node-pty is not thread safe across multiple Node worker threads. That does not directly describe DeepSeek Harness session architecture, but it is a reason to test actual parallel behavior instead of assuming that isolated UI tabs equal isolated PTY resources.

Use this checklist before making a rollout decision:

• [ ] Record the exact DeepSeek Harness version: v0.1.0-rc.7.
• [ ] Record the exact locked node-pty version.
• [ ] Record the Mac system version and CPU architecture.
• [ ] Record the Node runtime and shell startup mode.
• [ ] Run an input-echo Bash test.
• [ ] Run a progressive-output test.
• [ ] Verify a non-zero exit status.
• [ ] Cancel an active command.
• [ ] Confirm parent and child process termination.
• [ ] Test terminal resize if your workflow uses it.
• [ ] Run one real build task.
• [ ] Disconnect during an active task.
• [ ] Reconnect and inspect output, control, and process state.
• [ ] Run isolated parallel tasks.
• [ ] Compare workspace files with the previous release.
• [ ] Save the smallest failing reproduction.
• [ ] Decide whether to continue, restrict, or roll back.

For infrastructure teams, treat remote Mac delivery acceptance as a separate environment check. Validate the delivered machine, shell, permissions, runtime, workspace, and access path before treating a harness result as a software-only result. If you are comparing hosted environments, use the CALMVPS service overview as a neutral reference point for documenting the environment, not as evidence that the software candidate is stable.

Choose limited continuation when interactive Bash, output progression, cancellation, reconnect inspection, and workspace isolation all pass on the same Mac image.

Choose restricted use when short terminal commands pass but long builds, cancellation, or reconnect behavior remains unclear. Keep unattended jobs on the previous version until you have process-state evidence.

Choose rollback when PTY startup fails, input control breaks, cancellation leaves children running, sessions cross-contaminate, or the same reproduction fails only after the upgrade.

Do not expand procurement or remote Mac capacity merely because the dependency moved to a newer beta. The upstream release stream is still receiving compatibility and cleanup changes, including macOS and terminal-related fixes. A candidate dependency can improve one failure mode while exposing another.

If your current setup is a local Mac with a manually maintained runtime, its weaknesses are usually inconsistent installation state, difficult reproduction, and limited recovery after a machine or network interruption. A remote Mac workflow can improve repeatability and access, but it adds transport, session, permission, and process-supervision boundaries that must be accepted explicitly.

For temporary validation, isolated builds, or short-lived DeepSeek Harness trials, renting a remote Mac from CALMVPS can be easier to compare than changing your long-term workstation first. Start with the retest checklist, preserve the previous version, and use the recorded evidence to decide whether the environment is suitable for continued testing.