DeepSeek Harness Job Panel: Subagent Task Splits

A shared Job Panel shows more tasks in one place, but your files, permissions, and recovery paths are still separate engineering problems.

Fastest fix: assign work by task contract, not by subagent brand. Give every job one goal, one owner, one workspace, one permission boundary, and one acceptance artifact.

This guide is for:

• Independent developers splitting a large change across several subagents.
• Small engineering teams managing parallel repository writes.
• Platform engineers responsible for remote execution, credentials, approvals, and task recovery.

Last updated August 18, 2026. Release and architecture details were checked against the DeepSeek Harness rc.7 release notes, the official architecture documentation, and the Web UI guide.

The panel centralizes observation, not responsibility

The v0.1.0-rc.7 release notes confirm that Codex and Claude Code subagent tasks can be managed through Job Panel. That confirms an integration point. It does not, by itself, prove automatic conflict resolution, operating-system isolation, credential separation, or continuation after a process restart. (github.com)

The architecture documentation describes a plugin-based system with session events, scoped tools, filesystem providers, subprocess backends, sandbox backends, and job controls. Those are useful extension points, but the actual safety boundary depends on the active profile, provider, policy, workspace, and runtime environment. (github.com)

Start with these two tables before launching any task.

Split by task contract instead of Codex or Claude Code label

The useful comparison is not “which brand is better?” It is “what must this job be able to see, change, execute, and prove?”

A read-only research task needs repository visibility, search tools, and a way to cite file paths. It should not need write access. A code-editing task needs a bounded file scope, a known base revision, and a test command. A build task needs a stable dependency environment and enough time to finish, but it may not need permission to change source files. A deployment task needs a target, credentials, approval, and rollback procedure.

The official Web UI guide says that an agent can read and edit workspace files, run commands, delegate work, and maintain a plan. It also states that the UI asks before operations requiring approval under the active permission policy. That means you should treat the permission policy as an input to your task design, not as an invisible feature of the panel. (github.com)

For Codex and Claude Code, use a capability probe before assigning production work:

1. Give the subagent a read-only repository summary.
2. Ask it to identify the exact files it would change.
3. Run one harmless command.
4. Give it a disposable workspace with one small edit.
5. Check whether the panel records the job, output, changed files, and failure state as expected.
6. Only then expand the task scope.

This avoids a common mistake: assuming that a subagent supports a tool, permission, recovery path, or background behavior because its name appears in the Job Panel.

A task contract is more reliable than a model preference because it defines what failure means before the agent starts.

Use workspace ownership to control merge risk

Multiple subagents can inspect the same repository safely when they are read-only. Multiple subagents should not normally write to the same working directory at the same time.

A shared writable workspace creates at least four failure modes:

• Lost edits: one process writes a file after another process has read an older version.
• Invalid test evidence: a test result may include changes made by another agent.
• Unclear rollback: reverting one task may remove part of another task.
• False completion: an agent reports success because the expected file exists, even though another process changed it afterward.

Choose among three workspace strategies.

Read-only sharing

Use one checkout when every subagent is investigating, reviewing, indexing, or proposing changes without writing. This is the fastest option for repository maps, dependency analysis, API discovery, and test planning.

The output must contain file paths, assumptions, and recommended changes. Do not let a read-only analysis task silently become a write task because the agent found an easy improvement.

Isolated workspaces

Use one workspace per writer when tasks are independent and their file boundaries are clear. The workspace can be a separate checkout, branch, directory, or remote execution environment. The exact mechanism depends on your Git and host setup.

Isolation is justified when:

• The agents modify different features.
• Each task can be tested independently.
• One integration owner will review the resulting diffs.
• The cost of merging is lower than the cost of recovering a shared-directory conflict.

Do not call a directory “isolated” merely because it has a different panel row. Confirm the filesystem path, process environment, credentials, and Git state.

Serial merge

Use serial execution when tasks touch the same interfaces, configuration, migrations, generated files, or test fixtures. The first agent produces a diff and evidence. The next agent starts from the accepted result, not from the original base.

Serial execution is often faster than parallel execution for tightly coupled work because it removes repeated conflict repair. The goal is not maximum visible concurrency. The goal is minimum unowned state.

For more environment planning, compare the trade-offs in bare-metal macOS versus virtualization before placing concurrent jobs on one host.

Keep permissions narrower than the workspace

A separate workspace does not automatically create a separate security boundary. Your subagent may still inherit access to:

• Other directories through shell commands.
• Environment variables containing tokens.
• SSH keys or credential helpers.
• Network endpoints.
• Docker or virtualization sockets.
• Shared caches and package registries.
• The host process table or terminal sessions.

The DeepSeek Harness architecture separates filesystem, subprocess, sandbox, approval, and tool capabilities as different parts of the runtime. It also notes that a remote filesystem or subprocess provider can move Bash, PTY, and language tooling into another execution world. Verify which provider is active instead of treating the Job Panel as the isolation layer. (github.com)

Use this permission sequence:

1. List the readable paths. Include the repository, build cache, home directory, and temporary directories.
2. List the writable paths. Confirm whether the agent can edit source, Git metadata, configuration, or secrets.
3. List executable commands. Separate harmless inspection from package installation, code generation, deployment, and deletion.
4. Check network access. Decide whether the job can call package registries, APIs, remote Git hosts, or production endpoints.
5. Remove inherited credentials. Inject only the token needed for the task, and prefer short-lived credentials.
6. Add an approval gate. Keep human approval for destructive commands, external writes, deployment, and credential changes.

A Job Panel can tell you that a task is visible. It cannot prove that the task is confined to the path you intended. That proof comes from the runtime configuration and an acceptance test.

Make failure ownership explicit

A failed subagent task is not one event. It can mean a model error, a command failure, a permission denial, a timeout, a lost terminal, a remote connection loss, a workspace conflict, or an incomplete result reported as success.

Assign recovery responsibility before launch:

• Subagent: explain the failure and stop at the permitted boundary.
• Main agent: decide whether to retry, narrow, continue, or reject.
• Integration owner: review diffs and merge or roll back.
• Platform owner: restore the runtime, credentials, workspace, or host.
• Human approver: authorize high-risk continuation.

Do not allow an automatic retry to reuse a dirty workspace unless the contract explicitly permits it. First capture:

• Job identifier.
• Last successful operation.
• Last command and exit result.
• Changed and untracked files.
• Relevant logs.
• Test output.
• Network or credential errors.
• Unfinished steps.
• Recommended next action.

The main agent should be able to decide between accept, repair, and rollback without rerunning the entire task. If the only available output is “done” or “failed,” the job is not operationally recoverable.

Treat state visibility and state recovery as different tests

A panel status is an observation. A recovery guarantee is a system property that must be tested.

The release notes show fixes for session continuation after max-token truncation and improvements to the dynamic plugin panel. They do not establish that every external Codex or Claude Code process survives a host restart, a panel reload, a terminal exit, or a broken remote connection. (github.com)

Run these checks in a disposable repository:

1. Start a read-only subagent and confirm that its job appears in the panel.
2. Cancel it while it is idle and while it is executing a harmless command.
3. Force a timeout with a bounded sleep or equivalent safe operation.
4. Close the controlling process and inspect whether the child process remains alive.
5. Reload the Web UI and compare the displayed record with the actual process and filesystem state.
6. Restart the host or remote session.
7. Reconnect and inspect the workspace, logs, process list, and Git diff.
8. Attempt a continuation only after you know whether the previous process ended, paused, or duplicated work.

The architecture documentation distinguishes durable session events from live agent events and describes persistence, replay, fork, and resume as log-derived behavior. That is valuable for session history, but it should not be confused with guaranteed survival of every child process or external adapter. (github.com)

Never infer “still running” from “still visible.” Verify the process, the workspace, and the last durable artifact.

A five-step runbook for safe subagent jobs

Use this procedure for each new job.

1. Write the contract

State the objective in one sentence. Add the input revision, allowed files, forbidden files, commands, network policy, owner, deadline, and acceptance artifacts.

Bad objective: “Improve the authentication system.”

Better objective: “Update the token refresh handler in src/auth/refresh.ts, add focused tests, and do not change the database schema or deployment files.”

2. Select the smallest capable agent

Start with a task that can be evaluated quickly. Do not assign a broad refactor because the panel can launch several agents. Test whether the selected Codex or Claude Code integration can inspect the workspace, run the required command, produce a diff, and report failure evidence.

3. Lock the workspace model

Mark the job as read-only, isolated-write, or serial-write. Record the exact path and base revision. If another job owns a file, the new job must not write it.

4. Apply permissions and approvals

Set filesystem, shell, network, and credential permissions independently. Require approval for package installation, destructive commands, deployment, external writes, and secret access.

5. Accept by evidence

Require a changed-file list, patch or diff, test commands, test output, logs, known limitations, and unfinished items. A natural-language summary is supporting information, not proof of completion.

Decision branches for choosing the execution pattern

Use these conditions when deciding between one agent, serial agents, and isolated parallel agents.

• If the task has one outcome and touches one bounded area, choose one subagent. Keep the main agent as reviewer and owner.
• If several steps depend on the previous step's exact output, choose serial subagents. Each agent starts from the accepted result of the previous one.
• If tasks are independent, have disjoint write sets, and can be tested separately, choose isolated parallel workspaces.
• If agents need the same files but only for inspection, choose a shared read-only workspace.
• If any task needs deployment, credentials, destructive commands, or production access, add a human approval point and a named recovery owner.
• If you cannot describe the merge procedure before launch, do not run the tasks in parallel.
• If you cannot reproduce the task state from logs and artifacts, do not treat the task as resumable.

Frequently asked questions

The following answers cover the operational questions that usually appear after the first multi-agent run.

How do you manage subagents from DeepSeek Harness Job Panel?

Use the panel to locate, observe, cancel, and review jobs. Keep the contract and evidence in a durable project record as well. The panel is not a substitute for ownership metadata, filesystem controls, command policy, or recovery documentation. Assign one owner per job and one integration owner per repository change.

How should Codex and Claude Code split subtasks?

Split by capability and risk. Use either tool for read-only discovery after a small capability probe. Give only one agent write ownership for a file set. Use a separate verification job for builds and tests when you need independent evidence. Keep deployment and credentialed actions behind explicit approval, regardless of which subagent performs them.

Can multiple subagents modify the same repository at the same time?

Only when their writes are isolated and their merge responsibility is clear. A common repository path is suitable for concurrent reading, not unrestricted concurrent editing. If two tasks must touch the same interface or generated file, serialize them. Parallelism without a merge owner turns a visible speed gain into hidden repair work.

Who should recover a failed subagent task?

The owner of the task should make the recovery decision. The platform engineer should repair infrastructure failures. The integration owner should review and merge code. Keep these roles separate. Otherwise, the agent that caused a partial change may also decide that the change is safe, without independent evidence.

Does Job Panel guarantee that work continues after a restart?

Treat the answer as version- and adapter-dependent until tested. The current release and architecture materials document session persistence and job-related mechanisms, but they do not let you assume that every external child process survives every restart condition. Test the exact failure path in your own remote Mac or local environment before promising continuation to users.

Current setup versus a Mac-based execution environment

A shared laptop or generic virtual host may look cheaper at first, but it often brings hidden limits: one user session competing with background jobs, unclear process ownership, inherited credentials, and weak separation between parallel workspaces. It also makes it harder to reproduce the same shell, filesystem, and approval conditions when a subagent fails.

A dedicated Mac environment gives you a clearer execution boundary, predictable workspace ownership, and a better fit for teams that need repeatable macOS builds or long-running agent tasks. It is not automatically the right choice for permanent heavy workloads, physical-device access, or jobs that require a fully customized on-premises stack. For temporary validation, isolated experiments, or overflow capacity, MacDate’s bare-metal macOS pricing guide is a useful next comparison.

Start with two low-risk, independent jobs: one read-only repository survey and one small isolated edit with a focused test. Confirm ownership, permissions, cancellation, logs, and handoff before increasing concurrency. If the team then needs multiple agents to run for longer periods, use the Mac mini compute node guide to plan capacity rather than adding panel rows and hoping the runtime will resolve the boundaries for you.