[Arcadi4]

• Closes Missing agent environment detection for DeepSeek Harness #407

[github-actions]

Hi @Arcadi4. Thanks for contributing to cf!

During the open beta, we’re being very intentional about the changes we accept so that we can prioritise stability for GA. We’re limiting pull requests to contributions coordinated with the team in advance, so this PR has been automatically closed.

We’d still love to hear about your use case, so please make sure it’s captured in a cf issue. If the proposed change fits our priorities, we’d be happy to take another look at this PR.

[clanky-the-clanker]

💬 Approved with comments — The DeepSeek Harness detector follows the existing exact-marker pattern and is registered correctly. There are two non-blocking INFO notes: the session-ID test case doesn't assert the session ID, and there is no changeset. The upstream env-var contract could not be checked from this environment.

Findings: 2 info

_{The decision is advisory: this comment never approves, blocks or requests changes on the pull request.}

🔧 Fix with your agent

Paste the following into your coding agent to investigate and fix these issues.

Fix the following code review issues found in pull request #408.

Before making changes, review each issue and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g., the fix would require disproportionate changes
  for minimal ROI, or the finding is factually incorrect), explain why
- If you need to clarify something before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

## INFO (2)

### [Code Quality] The 'DeepSeek Harness with session' case never asserts that DSH_SESSION_ID is used as sessionId or listed in signals, so that branch is untested. Add a dedicated assertion like the Qwen test has.
- **File:** packages/cli/src/__tests__/lib/agent-context.test.ts:15

### [Code Quality] No changeset was added. Agent detection affects the X-CF-CLI-Agent header and telemetry, and the repository guidelines ask for a changeset for user-facing cf changes.

---

📋 Code Quality: 💬 2 info

The detector is correct and consistent with the other detectors. The session test case is weak and there is no changeset. The upstream DSH_* contract was not checked.

Recommendation: 💬 Optional Nits

• [INFO] The 'DeepSeek Harness with session' case never asserts that DSH_SESSION_ID is used as sessionId or listed in signals, so that branch is untested. Add a dedicated assertion like the Qwen test has. (packages/cli/src/__tests__/lib/agent-context.test.ts:15)
• [INFO] No changeset was added. Agent detection affects the X-CF-CLI-Agent header and telemetry, and the repository guidelines ask for a changeset for user-facing cf changes.

View full review

Your question: are DSH_SHELL=1 and DSH_SESSION_ID the right markers, and the only ones?

I could not check this. The environment had no network access, so I could not open the evidence permalink (deepseek-ai/deepseek-harness@b13bbc0, packages/shell/shell-env/src/index.ts#L158-L162). The repository has no copy of the harness source, so I also could not confirm these three things:

• the harness sets DSH_SHELL to exactly "1";
• DSH_SESSION_ID is the real variable name;
• the harness exports no other marker.

Please open that permalink and confirm all three before merging. Points to check there:

• The exact value of DSH_SHELL. isExact(environment, "DSH_SHELL", "1") is a strict match, so values like true or yes would not be detected.
• Whether the harness also sets AI_AGENT. Pi and Crush match on the generic AI_AGENT=<name> convention as well as their own markers. The new detector has no such fallback. If the harness sets AI_AGENT, add that path; if it doesn't, the current code is enough.
• Whether the harness exports a model or invocation id. If it does, they could be reported the same way the Qwen detector reports them.

A search of the repository found no other DSH_ or DeepSeek references, so this change does not conflict with any existing detection path.

Wiring

• The detector is registered in agentDetectors after Pi and before Cursor. That matches the ordering comment: direct agents first, host surfaces after.
• The harness id deepseek-harness reaches the X-CF-CLI-Agent header and telemetry unchanged. Nothing else maps ids and would need updating.

Findings

1. [INFO] packages/cli/src/__tests__/lib/agent-context.test.ts:15-19: the "DeepSeek Harness with session" row runs through the shared it.each. That check only asserts isAgentic, the harness id and the match count, so the DSH_SESSION_ID branch is never actually tested. Add a dedicated test, like the Qwen one, that asserts context.sessionId === "dsh-session" and that signals includes DSH_SESSION_ID.
2. [INFO] The repository guidelines ask for a changeset (.changeset/<name>.md, "cf": minor) for every user-facing change. A new detected agent changes the X-CF-CLI-Agent header and telemetry, so this may qualify. Earlier detectors don't seem to have had changesets, so this is minor.

---

✅ All other checks passed

📝 Documentation: ✅ LGTM

No documentation issues. The evidence comment above the new detector follows the same convention as the other detectors.

---

_{Reviewed commit: ee0e725c}

[MattieTK]

clanky review, check that these are the correct instructions for identifying the deepseek harness and there are no other ways that deepseek does this

[pkg-pr-new]

npm i https://pkg.pr.new/cf@408

commit: d9f4994

[petebacondarwin]

The PR’s detector is correct:

• DSH_SHELL is set to exactly "1".
• DSH_SESSION_ID contains the current agent’s session ID when available. Source
• I found no AI_AGENT fallback or standard model/invocation ID exports.
• Both Bash and PowerShell receive these variables.

Other exported variables describe home/profile paths and the web URL; they aren’t needed for detection. No harness-settings changes are necessary.

[Arcadi4]

clanky review, check that these are the correct instructions for identifying the deepseek harness and there are no other ways that deepseek does this

Checked previously, and turns out they don't have compatibility measures for other harnesses via environment variables.