DeepSeek Harness auto permission deadlock: projections fix

If you have ever used /permission auto in DeepSeek Harness (DSH) to cut down on approval prompts, you have probably met cannot get required service "sessionProjections" in inactive context. The tool is not broken. Permission presets and auto-review wait for each other during startup: the preset needs the approval entry that auto-review provides, while auto-review waits for the preset to publish its projection. A restart sometimes helps because construction order changes, but as long as a session keeps a durable auto, the deadlock returns.

How to confirm a DeepSeek Harness permission deadlock

Bottom line: you are in the right place when the error contains inactive context, the permission card shows a startup failure or auto-review stays pending, and new sessions still fail to use tools. Run these checks:

1. Search the startup log for cannot restore preset "auto" without its active integration or pinInitialPermission; expected: a construction-time throw.
2. Open /permission and change a preset; expected: the page opens, but the shield is missing and the change does not apply.
3. Read the auto-review row in the plugin list; expected: it stays at pending rather than failed.

According to the reproduction in the discussions, these three appearing together point to the circular dependency between the construction-time scan and autoAdmit (#10233, #9882). For baseline permission settings, see permission approval configuration.

How the DSH circular deadlock forms

Bottom line: permission-presets scans loaded sessions during construction and tries to restore presets, while the auto preset depends on an autoAdmit that auto-review cannot register until permissionPresets is available.

Two source locations line up with the symptom:

• permission-presets/src/index.ts:248-250 calls pinInitialPermission during construction, and :428-436 throws when no active integration exists.
• auto-review's registerAuto depends on the permissionPresets service, so it never runs before the service publishes.

The throw alone is not the worst part. It happens before the projection is registered, so the permissions projection never appears, every reader of sessionProjections sees inactive context, and all subsequent tool calls fail.

Why a restart sometimes helps

• If auto-review finishes registering before the construction scan runs, autoAdmit exists and no deadlock occurs.
• If a session still carries a durable auto, a later restore can reproduce the order that deadlocks.
• More plugins and more concurrent initialization make the order less stable, which is why the failure looks intermittent.

Three DeepSeek Harness fixes for the preset deadlock

Bottom line: disable auto-review when you need the host now, edit the session header when only a few sessions are affected, and change the construction scan when you can ship a core fix; the three are compatible.

Fix 1: disable auto-review so the host can boot

This is the cheapest and fastest relief when you cannot even reach the settings page. With auto-review off, permission presets fall back to fixed modes and old sessions still open.

1. Open ~/.dsh/profiles/<your profile>/cordis.patch.yml; expected: the profile patch file is visible.
2. Find the auto-review row and set disabled: true; if the row is absent, add a same-id disable entry; expected: the row is explicitly disabled.
3. Quit DSH completely, including the tray process, then start it again; expected: the log no longer shows a restore preset error.
4. Open settings and change every session that still uses auto to default or ask; expected: the permission shield returns.
5. Re-enable auto-review only after step 4; expected: it does not immediately fall back to pending.

Fix 2: remove the durable auto preset from the session header

When only a few sessions trigger it, editing the header preset is more precise than disabling the plugin, but back up first. The durable preset lives in session metadata, not global configuration.

1. Quit DSH and back up the entire ~/.dsh/storages/ directory; expected: a complete restore point exists.
2. Under storages, find the metadata file for the failing session by modification time and search for "preset" or "auto"; expected: the header with a durable auto is located.
3. Change that session's preset field to default; do not delete the whole header; expected: the file remains valid session metadata.
4. Restart and open the session; expected: no cannot restore preset error.
5. If the error persists, another session carries the same field, so repeat step 2; expected: the log stays clean after the last header is fixed.

Fix 3: make the construction scan degrade gracefully

This is the only root fix. Either turn a failed preset restore into a warning plus a deferred repair, or move the scan from construction to first activation. The patch shape discussed is pinInitialPermission(session, { reject }) plus a second sweep.

1. In permission-presets/src/index.ts, change the construction-time scan so a failed pinInitialPermission logs a warning and marks the session for repair instead of throwing; expected: one bad session no longer blocks startup.
2. Add an idempotent sweep after registerAuto: re-walk marked sessions and attach autoAdmit once it exists; expected: no session remains marked.
3. In the restore preset branch at :428-436, add a dedicated error code for "integration not ready"; expected: it is not confused with a configuration error.
4. Regression-test with a session carrying durable auto: boot, restore, switch presets, restart; expected: no pending state.
5. Add a unit test where auto-review initializes after permission-presets; expected: the degraded path is proven.

Verify DSH recovery and avoid regressions

Bottom line: at least one new session, one restored session, and two restarts are needed to show the deadlock is gone. Verify:

1. Create a session and make a request that triggers a tool call; expected: no inactive context.
2. Open an old session; expected: the shield is present and /permission changes apply immediately.
3. Restart DSH twice; expected: auto-review is not pending on either run.
4. If you re-enable auto-review, start with a low-risk tool; expected: the review call completes before you widen scope.

Avoid these traps:

• Do not delete the whole ~/.dsh directory; that removes session history and plugin configuration, so locate the specific session first.
• inactive context can come from other unloaded fibers; this article covers only the permission-preset plus auto-review case, so use the generic sessionProjections path if it persists with auto-review off.
• Fix 3 is core-side and may be overwritten by upgrades; if you are only a DSH plugin user, prefer the first two.
• No official fixed version is listed in the discussions; 0.2.1-rc.2 still reproduces, so check release notes for changes to preset restoration.

DeepSeek Harness permission preset FAQ

Q: Why does DeepSeek Harness report inactive context right after enabling /permission auto? A: DeepSeek Harness reports inactive context because permission-presets and auto-review deadlock during construction, not because session data is corrupt. The preset scan throws on a durable auto, the permissions projection never publishes, and auto-review waits forever; disabling auto-review is the fastest workaround.

Q: Why does DeepSeek Harness fail to restore old sessions after showing 2 entries did not activate? A: DeepSeek Harness shows 2 entries did not activate when the stored session header carries the auto preset while autoAdmit is not registered yet. Disable the auto-review row in the profile so permission-presets can finish construction, then reset the old sessions to default or ask.

Q: Why does auto-review stay pending in DeepSeek Harness while the permissions shield disappears? A: In DeepSeek Harness, a pending auto-review and a missing shield are two views of one failure. The shield disappears because the permissions projection never published; pending means auto-review is waiting for that service, both caused by the construction-time throw.

Q: Must I delete the whole ~/.dsh directory after DeepSeek Harness 0.2.1 breaks new sessions? A: DeepSeek Harness new-session failures do not require deleting the whole ~/.dsh directory. Identify whether the durable auto preset is stored per session or as the global default; edit the session header or the profile permission configuration, and only rename storages for isolation if the session cannot be found.