cache-sentinel

LIMITATIONS

Known limitations

- **Running several profiles at the same time**: `state.json` is stored per profile (`$DSH_HOME/cache-sentinel/profiles/<profile>/state.json`), so modes, `baselineAt`, and unarchiving records do not overwrite each other. When you upgrade from an earlier version, each profile copies the old `$DSH_HOME/cache-sentinel/state.json` on its first start (the old file is kept and not read again). Where the profile name is not available, the old file is used. The archive state, however, lives in DSH's shared `$DSH_HOME/storages/workspace.json` and cannot be split by a plugin: DSH reads it once at startup, never reloads it, and every write replaces the whole file. If two profiles run at the same time, archiving / unarchiving / pinning in one can therefore be lost by a write from the other. **If you use `archive` or `both`, enable it in only one profile at a time.** - Because M3E does not load client bundles from other plugins, displaying the pre-send banner requires support on the M3E side (the in-conversation notice when blocked is displayed by the Host side alone). - In subagent sessions, `/unlock` cannot be executed from the GUI. Messages from the parent agent are not blocked, but a message you send directly to a subagent from the GUI is blocked if the subagent's cache has expired. - Input that comes from your action but is not a plain send is not blocked: - Creating a goal with `/goal <objective>`, editing it with `/goal edit`, or resuming it. The goal runs even after the cache has expired. - `/goal` with attachments. The attachments enter first as a plain send, so they are blocked and discarded, and the goal runs without them (behavior read from the code; not verified on a running DSH). - Answering a question (`ask_user_question`) after the cache has expired. Blocking it would discard the answer. The question goes back to waiting for an answer, but having already answered, you are unlikely to notice that you need to answer again. - A step that follows a tool run longer than `idleMinutes` is sent without the cache, but the plugin does not detect it (nothing is logged). The last response time is refreshed by the `step/end` written when the tool finishes. - Automatic title generation (`session-title-first-prompt-llm`) calls the model independently on the first send and is outside the gate (only on the first send in new sessions or forks, and only the first message is sent). - The actual prompt cache lifetime depends on the provider and request contents. This plugin is an approximation based solely on elapsed time.