DeepSeek Harness Codex Subagents: Where Is the Result?

A DeepSeek Harness task delegates work to Codex, receives a child identifier, and then appears to stop producing useful information. Should you wait, restart the task, or change the API provider?

Start by checking which result you are expecting.

An acknowledgement that a child started is different from a completed answer. The absence of live tool activity in the parent conversation also does not prove that the child has stopped working.

This tutorial explains how to test @deepseek-ai/dsh-subagent-codex, distinguish missing progress from missing completion, and verify the model connection without launching duplicate work.

1. Understand the handoff before changing settings

The official Codex subagent package documentation describes a one-shot delegation into a fresh Codex thread. Native Codex configuration and authentication remain authoritative.

The shared delegation tool documentation distinguishes the start acknowledgement from the later completion notice.

For troubleshooting, separate these checkpoints:

A child identifier establishes only one of these checkpoints.

Do not label a task successful because delegation was accepted. Equally, do not resubmit merely because the parent conversation does not show each intermediate action.

2. Begin with a read-only fixture

Use a small test workspace rather than a production change.

Create a file named handoff-fixture.txt containing these synthetic facts:

Project: Cedar
Retry limit: 2
Owner: Platform Team

Ask the parent to delegate this task:

Read handoff-fixture.txt in the selected workspace.

Return:
- The project name.
- The retry limit.
- The owner.
- Whether you could read the file.

Do not modify files, install packages, or access external services.
If the file is unavailable, report that limitation instead of guessing.

The file is deliberately simple. You already know the expected answer, so the test can establish whether the child received the task, accessed the intended workspace, and returned useful information.

Avoid putting the expected values into the task itself. Otherwise, the child could repeat the prompt without reading the file.

This test does not establish coding quality. It establishes a basic delegation path.

3. Confirm the selected workspace

A correct parent conversation can still delegate into an unintended directory.

Record the workspace associated with the task and the location of the fixture. Check the filesystem from the environment where the child runs, especially when containers or remote workspaces are involved.

If the failure includes “unable to determine project root for task,” follow the existing Codex project-root diagnostic guide before changing model credentials.

Keep the investigation narrow.

A workspace problem needs evidence about directories and access. An authentication problem needs evidence about the selected provider and credentials. Changing both at once makes a successful retry harder to explain.

4. Do not expect a full execution transcript in the parent

The current Codex provider returns selected answer text or a safe failure diagnostic. Its package documentation does not promise a live progress stream, continued conversation with the same child, or automatic rollback after cancellation.

Design your parent workflow around that boundary.

For the fixture test, the result you need is a correct answer about the file. You do not need the parent to receive every file-read event or internal message.

For a code-changing task, the final response alone is insufficient. Inspect the resulting diff and run the agreed checks separately.

A report saying “tests passed” should be verified against actual test evidence where your workflow makes it available. If that evidence is unavailable, record the limitation instead of promoting the statement into a verified result.

5. Write a self-contained task

A fresh child should receive the information required to complete its assignment.

A useful handoff includes:

• A specific objective.
• The files or directories in scope.
• Relevant constraints.
• The expected deliverable.
• The checks that define completion.

For example:

Objective:
Review input validation in src/importer.py.

Scope:
Read src/importer.py and tests/test_importer.py.
Do not modify files.

Acceptance:
Report only issues supported by these files.
For each issue, include the file, relevant function, triggering input,
and expected behavior.

Limitations:
If necessary context is missing, identify it explicitly.
Do not assume that a suggested command was executed.

This is more useful than “continue the investigation” when the child does not have the context needed to interpret that instruction.

Keep the assignment small enough that one completion can contain the evidence the parent needs.

6. Separate model access from result delivery

The parent using DeepSeek does not establish which model or account the Codex child uses.

Inspect the child's actual configuration. OpenAI's configuration reference is the appropriate reference for native Codex settings.

When using an API gateway, verify the child's provider, endpoint, model ID, authentication method, and required protocol.

TreeRouter belongs at this model-access layer. A successful generic chat request is useful, but it does not establish compatibility with every Codex capability.

Use the TreeRouter Codex connection guide to check the relevant integration path, then rerun the small fixture through the child.

The two tests answer different questions:

1. Can this account access the selected model route?
2. Can this delegated Codex task complete through that configuration?

7. Prevent duplicate work while investigating

Before retrying, determine whether the original child is still running.

Maintain a small application-side record:

{
  "task_id": "review-001",
  "attempt": 1,
  "child_id": "record-the-returned-identifier",
  "state": "accepted",
  "input_version": "fixture-v1",
  "result_verified": false
}

This is a suggested tracking format, not a DeepSeek Harness configuration schema.

Use distinct states for accepted, completed, failed, cancelled, and unresolved attempts. Do not convert a missing completion notice into an empty successful answer.

If a task is cancelled after making changes, inspect those changes before rerunning it. A second attempt may otherwise repeat an action or work on a partially modified project.

For the initial fixture, keep the task read-only so these recovery decisions remain simple.

8. Verify the outcome with controlled failure cases

After the successful fixture, run two additional tests.

First, request a file that does not exist. The child should report the limitation, not invent its contents.

Second, remove a required detail from the task. Check whether the returned answer identifies the missing information rather than claiming completion.

Record the observed result:

These cases help distinguish a functioning delegation path from a workflow that merely produces plausible text.

Frequently asked questions

Does no live progress mean the child is stuck?

No. Compare the behavior with the provider's documented result contract and check the actual lifecycle state.

Can I change the parent's model to change the Codex child?

Do not assume so. Confirm the child provider and native configuration independently.

Should I retry after every delay?

No. First establish whether the previous attempt is still active or has already produced changes.

Start with one verified delegation

Once the fixture works, move to a small code-review task with a known acceptance condition.

For a gateway-based setup, create a TreeRouter account, confirm the required Codex route, and test that route before expanding the workflow.

A useful first milestone is one accepted child, one identifiable completion, and one result you can independently verify.