DeepSeek Harness tool calls fail in inactive context

A session suddenly reports cannot get required service "sessionProjections" in inactive context, and every tool call in that session fails, regardless of tool or model, while a brand-new session works normally. This is a context lifetime problem in DeepSeek Harness (DSH): the caller holds the ctx of a Cordis fiber that has already unloaded, and the service itself is still published by an active one (source).

Confirm the failure is inactive context in DeepSeek Harness

Treat it as this defect only when the message contains both sessionProjections and inactive context; a 403 points at permissions and a provider name or 400 points at the model.

1. Read the error text and confirm the service name and inactive context appear together. Expected: both present and no status code.
2. Try an unrelated tool in the same session, such as bash, a file read, or search. Expected: it fails the same way.
3. Open a new session and run the same tool. Expected: it works, so the tool is not the variable.
4. Restart the host and retry the old session. Expected: it may work briefly, then fail again.
5. Check whether a DSH plugin was reloaded or disabled recently. Expected: the time matches the first failure.

The discussion traced the throw to the get trap in vendor/cordis/src/reflect.ts:136-171: at :163 it checks prop in fiber.inject and throws before the lookup continues upward. The message therefore means the read goes through an unloaded fiber's context, not that the process never had the service (#10272).

Why a DeepSeek Harness session keeps a dead context

The session cached a ctx while its fiber was alive, and nothing replaced the reference when that fiber unloaded.

1. A plugin or session obtains ctx during initialization and stores it on a long-lived object. Expected: the reference outlives the fiber.
2. That plugin is hot-reloaded, disabled, or unloaded after an error. Expected: the fiber becomes inactive.
3. The session object still holds the old ctx and nothing invalidates it. Expected: the reference looks usable.
4. The next tool call reads sessionProjections through that stale context. Expected: the get trap runs.
5. The trap finds the service in the fiber's inject list, but the fiber is inactive, so it throws. Expected: the call fails.
6. The session keeps reusing the same context. Expected: every later call fails at the same point.

Hot reloads, frequent plugin restarts, and long-running sessions all raise the odds. Note that "inactive" describes the context, not the service: the service name appears only because it was the read target.

Fix 1: move the work to a new DeepSeek Harness session

This is the fastest recovery when the current conversation is replaceable or its contents can be copied out.

1. Copy the last few turns' conclusions, file paths, and open tasks. Expected: a handoff note you can paste.
2. Create a new session, paste that context, and run a read-only tool. Expected: the tool returns normally.
3. Paste any important tool output as well. Expected: the model continues without re-running expensive tools.
4. Archive the old session. Expected: it cannot be reopened by accident.
5. Continue the task in the new session. Expected: context is continuous and tools work.
6. Watch for ten minutes. Expected: the same error does not return.
7. Mark the old session read-only. Expected: no further failed results are appended to it.

The cost is the implicit context left behind. Write conclusions down before moving, and do not expect the model to remember them.

Fix 2: restart DeepSeek Harness so the session rebinds

A restart clears the old fiber and context and recovers some sessions; if the error survives a restart, the bad reference was persisted and you need Fix 1.

1. Quit DeepSeek Harness completely. Expected: no DSH process remains.
2. Start it again and open the failing session. Expected: the session loads.
3. Send a plain text message first, then trigger one tool call. Expected: the tool call completes.
4. If tools work, continue; if the same spot fails, switch to Fix 1. Expected: no repeated restarts.
5. Note what you did before the failure. Expected: a timeline that shows whether a plugin reload is involved.
6. Call two more tools. Expected: no delayed relapse.
7. Read the startup log for fiber initialization order. Expected: no plugin failed to load.

A restart rebuilds runtime state once. If you run plugins that reload often, the failure will probably return, and repeating restarts only wastes time.

Fix 3: stop caching ctx at the DeepSeek Harness call site

The durable fix is to keep ctx only for a bounded lifetime, clear it when the fiber disposes, and resolve services through the active context.

1. Find the session or plugin field that stores ctx. Expected: one known cache site with a documented lifetime.
2. Clear that reference in the fiber's dispose hook, or replace it with a lazy lookup. Expected: the reference disappears at unload.
3. Read sessionProjections from the current active session context. Expected: every read resolves through a live fiber.
4. Add the fiber id and unload reason to the thrown error. Expected: the next report names the fiber that died.
5. Add a test that unloads the fiber and then invokes a tool. Expected: it fails if a stale context is reused.
6. Describe the reproduction path in the pull request. Expected: maintainers can compare against 0.2.1-rc.2.
7. Grep the codebase for other long-lived ctx fields. Expected: no second cache site is left behind.

A lazy lookup costs one extra resolution, but it is safer than holding a reference that can expire at any unload. Prefer it on read-heavy paths.

Verify and set bounds after a DeepSeek Harness reload

The repair is complete only when tools survive a plugin reload and a host restart, not just the next call.

1. Run three different tools in the repaired session. Expected: none reports inactive context.
2. Trigger a plugin reload and call a tool again. Expected: the reference refreshed and the call succeeds.
3. Restart the host and reopen the session. Expected: it still works.
4. Open a fresh session as a control. Expected: no new missing-service errors.
5. Watch the tool failure rate for an hour. Expected: no repeated error at the same point.
6. Check that the session log still appends. Expected: tool results are not missing.
7. Repeat one tool call five times. Expected: all five succeed with identical output.

When only some tools fail, group them by type before drawing conclusions; two error paths in one session should not be merged into one.

Four limits apply: the service is almost always healthy, a restart does not always rescue the original session, hot reload is the highest-risk operation here, and switching models does not rebuild ctx. No official fixed version appears in the discussion; for the related startup deadlock, see permission auto deadlock.