DeepSeek Harness source dev: submodule, worktree, fork cron

TroubleshootingPublished 2026-10-17Author: DeepSeek Plugin Market
DeepSeek Harnesssource developmentgit submodulepnpm installcreate_worktreeGitHub Actionsfork
Three environment traps block DSH source work: pnpm install fails in submodule checkouts, create_worktree fails on old git, and fork cron jobs error daily.

When you join DeepSeek Harness (DSH) development from source, three typical "environment difference" problems block the first step: after checking out the repo as a submodule, pnpm install always fails (the worktree config key the install script wants to enable conflicts with the submodule's existing key); create_worktree fails 100% of the time on older git (it unconditionally prepends an option only newer versions have); and a forked repo inherits the scheduled workflow and errors every day for a missing upstream secret. None of the three is a product defect — they are "local/CI environment differences that were not covered" — so the troubleshooting approach is equally consistent: first confirm which checkout method, which git version, and which repo you have, then compare against the known limits (#9856, #9676, #9499).

DeepSeek Harness install after a submodule checkout always fails

The conclusion: when the repo is checked out as a submodule, git writes the worktree path into the shared config (standard behavior), while the install script needs to enable a worktree-scoped hooks-path config — meeting that existing key it throws immediately; the script has no submodule branch, and the "move it away" advice in the error is not actionable. The error shape is "cannot enable an extension config because it lives in shared config" (#9856).

DeepSeek Harness submodule three-step handling

  1. Confirm the criterion: it only reproduces as a submodule; a normal clone installs fine (#9856).
  2. Workaround (verified): run the install in CI mode so the script takes the short-circuit branch:
bash
CI=true pnpm install
#   expected: install succeeds, and the install check is not re-run by later scripts

The thread confirms this path short-circuits the check and the dependency verification no longer runs after install (#9856).

  1. Fix direction: add submodule detection to the script and use a local hooks-path config in that case; a dedicated environment variable could also override it (the thread confirms the existing variables do not cover this check, so one must be added or adjusted) (#9856).
  2. Verify: re-run CI=true pnpm install in the submodule checkout; expect no error and normal subsequent dev commands (#9856).

DeepSeek Harness create_worktree fails on older git

The conclusion: the capability unconditionally prepends --no-lazy-fetch to every git command, and that option was only added to the worktree subcommand in newer versions — so on older git it reports "unknown option" on the very first step. This was fixed in dsh-v0.2.1-alpha.3 (confirmed by a community reply) (#9676).

DeepSeek Harness create_worktree three-step handling

  1. Confirm the criterion: the error explicitly says "unknown option --no-lazy-fetch"; git --version is below the version that introduced it (the boundary given in the thread is git < 2.42) (#9676).
  2. Option one (least effort): upgrade git to a version that supports the option (#9676).
  3. Option two (if you have upgraded DSH): upgrade to dsh-v0.2.1-alpha.3 or later, which has the fix (#9676).
  4. The patch is worth remembering (if you maintain the tool): gate by version (only pass the option on ≥ 2.42), move the probe after the first command, and explicitly refuse some partial-clone cases in preflight — the thread notes the patch took local tests from "many failures" to "mostly passing" (#9676).

DeepSeek Harness daily fork cron job failure

The conclusion: the schedule trigger condition is written too broadly (it only excludes pull-request events), so schedule events also run in forked repos; and it needs an upstream-repo secret that a fork does not have, so it hard-fails in preflight. The symptom is a workflow failure notification once a day after forking, consuming quota (#9499).

DeepSeek Harness fork cron three-step handling

  1. Confirm the criterion: the notification comes from a nightly scheduled workflow; the error happens in preflight because a secret is missing; it only occurs in forked repos, upstream is fine (#9499).
  2. Fix (recommended, upstream-friendly): add a repo guard before the existing condition (requiring the repo to equal the upstream repo) so the schedule trigger is skipped in forks. A job-level skip is recorded as success, not a red cross — this point matters, it avoids "the fix makes it more visible" (#9499).
  3. The self-only approach: disable or delete the workflow file in your own fork (#9499).
  4. One easy trap: the thread warns that the repo name literal is recorded in different forms; before changing the guard, do a one-off manual trigger to print the actual repo name and confirm the spelling (#9499).
  5. Verify: after the change, watch one nightly cycle; expect no more failure notifications (#9499).

DSH plugin troubleshooting notes

All three belong to "environment differences", so the first step is always to confirm the environment: checkout method / git version / repo ownership. Seven points:

  1. "Only reproduces as a submodule" is the first criterion (#9856).
  2. The CI=true workaround is verified and does not re-trigger the check (#9856).
  3. "Move it away" in the error is not actionable: don't follow it, use an environment variable or a patch (#9856).
  4. For "unknown option", suspect the version before the arguments (#9676).
  5. This one is fixed: available since dsh-v0.2.1-alpha.3, stop hand-rolling a bypass (#9676).
  6. Fork cron jobs need "add a guard", not "turn off upstream": change the condition, not someone else's workflow (#9499).
  7. Fix status honestly: the submodule one is not fixed (only a verified workaround); the create_worktree one is fixed in 0.2.1-alpha.3; the fork cron one is an upstream workflow that needs its condition changed (a repo config, not product code).

Source development and build problems often have to be read together with "dependencies and plugins". If you set up several profiles locally for verification, instead of hand-typing commands everywhere to compare, use a visual plugin marketplace like DSH Plugin Hub: the installed list carries sources and versions, and install/uninstall history and system logs sit in one panel.

Settings

Source: Discussion #9856, Discussion #9676, Discussion #9499.

FAQ

After checking out the DeepSeek Harness repo as a submodule, pnpm install always fails saying it cannot enable a git extension config. What causes it and how do I fix it?

In DeepSeek Harness, checking out the repo as a submodule makes pnpm install always fail, because a submodule's git worktree path is written into the shared config by the parent repo, while the install script needs to set a hook path within the worktree scope and throws as soon as it meets that config key. The verified workaround is to set the CI environment variable to true at install time (for example run the install with a CI=true prefix) so the script takes a short-circuit branch, and after a successful install it will not re-run its verification.

DeepSeek Harness create_worktree reports an unknown option --no-lazy-fetch — did I mistype an argument?

DeepSeek Harness's create_worktree reporting an unknown option --no-lazy-fetch is not a mistyped argument; the git version is too old. That option was only added to the worktree subcommand in a newer git, while the tool unconditionally prepends it to every git command, so on older git it fails on the very first step. Upgrade git to a version that supports the option; if you maintain the tool, the fix is to detect the version first and only pass the option when the condition is met.

Why do I get one workflow failure notification every day after forking DeepSeek Harness?

After forking DeepSeek Harness you get one workflow failure notification every day, because the schedule trigger condition is written incorrectly, so schedule events are treated as satisfying it and the nightly job runs in forked repos too. It needs an upstream-repo secret that a fork does not have, so it hard-fails in preflight. The fix is to add a repo-must-equal-upstream guard before the existing condition; a job-level skip is recorded as success, so no red cross appears.

What do these three DeepSeek Harness source-development problems have in common?

These three DeepSeek Harness source-development problems all belong to local/CI environment differences: a submodule has different git config from a normal checkout, older git lacks a new option, and a fork lacks the upstream secret. So the common troubleshooting approach is to first confirm which checkout method, which git version, and which repo you have, then compare against the known limits.

In a fork, how do I keep the DeepSeek Harness scheduled job from consuming quota?

In a fork you can keep the DeepSeek Harness scheduled job from consuming quota in two ways. First, add the repo guard as the discussion says so the schedule trigger is skipped directly in non-upstream repos. Second, disable that workflow in your own fork (turn it off in the UI or delete the workflow file). Note the first approach is friendly to upstream maintainers, while the second only solves your own problem.

Related Terms

core.worktree (git submodule)
core.worktree is the git config key that records a working tree's path. When a repo is checked out as a submodule, git writes the module's worktree path into the shared config, which is standard version-control behavior. If an install script needs to enable a worktree-scoped config key, it will fail because that key already exists.— https://github.com/deepseek-ai/deepseek-harness/discussions/9856
create_worktree
create_worktree is the DeepSeek Harness capability that creates an independent worktree checkout, giving a clean copy of the code without disturbing the current workspace. It works by calling git's worktree subcommand, so it is limited by the local git version's capabilities.— https://github.com/deepseek-ai/deepseek-harness/discussions/9676
--no-lazy-fetch
--no-lazy-fetch is an option added to the git worktree subcommand in newer versions to disable lazy fetching. It is not in older versions' option table, so when it is used unconditionally older git reports it as an unknown option.— https://github.com/deepseek-ai/deepseek-harness/discussions/9676
schedule trigger
A schedule trigger is an event type in CI that runs a workflow at a planned time. If the condition treats every non-pull-request event as allowed, schedule events run in forked repos too, exposing fork-only problems such as a missing upstream secret.— https://github.com/deepseek-ai/deepseek-harness/discussions/9499

Sources