[Feature]: dsh plugin ignores workspace config, has no per-workspace memory opt-out

Aperta
  • Qualcosa non va?
#7,483 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@dongasai ci sta già lavorando.

Dal 12/11/2026.

  • #7482 di @dongasai — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
1/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
python
Ambito
backend

Direzione di ricerca

The issue identifies examples/dsh-memory-plugin and memory-plugin-shared/lib/agent-hook-runtime.mjs; start by reviewing the open pull request #7482, which implements this work. The proposed behavior is to resolve the full configuration from session.header.cwd and support workspace-level enabled; done means workspace settings govern each session and enabled: false prevents session setup and memory requests.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Issue Origin
  • Observed or reproduced in a real environment
  • Inferred by an AI agent and not observed or reproduced
Problem Statement

The workspace file <root>/.openviking/config.json is documented as the place a
repository states how it wants to be remembered, and recall.enabled /
capture.enabled are listed as workspace keys. In the DeepSeek Harness plugin
(examples/dsh-memory-plugin) neither one has any effect.

The cause: OpenVikingRuntime.stateFor() re-resolves only the peer against
session.header.cwd — it calls resolveConfig(input, process.env, cwd).effectivePeer
and keeps every other knob from the configuration the plugin resolved once at
process start. In web (and Desktop) that start directory is the profile
directory, not the session's workspace, so a workspace-level setting is read into
a configuration object nothing consults.

Reproduction (against 0.5.34, dsh 0.2.2-rc.1, profile launched from ~):

  1. Create <ws>/.openviking/config.json with {"version": 1, "capture": {"enabled": false}}.
  2. Open a session whose header.cwd is <ws>.
  3. resolveConfig({}, process.env, "<ws>").autoCapture is false, but the runtime
    state that actually governs capture still reports autoCapture: true, and the
    conversation keeps being captured.

The same gap means there is no way at all for a directory whose content must not
leave the machine to stay out of memory: enabled exists as a knob
(OPENVIKING_MEMORY_ENABLED), but it is not a workspace key, and even if it were,
the per-session resolution above would ignore it. The sibling harnesses do honour
cfg.enabled === false (memory-plugin-shared/lib/agent-hook-runtime.mjs), so
dsh is the one integration where the documented workspace switches silently do
nothing.

Prior Art

Searched the tracker before filing; no existing issue asks for this, and these
are the nearest threads:

Thread State What it asks for Difference
#6443 Open A per-process/per-session privacy switch (OPENVIKING_AUTO_CAPTURE=0) that guarantees zero upload while keeping recall; it explicitly rejects OPENVIKING_MEMORY_ENABLED=0 as "disables the extension entirely" That switch is still per process; the gap reported here is that the per-workspace file cannot express either intent in dsh — its keys are read and ignored
#4170 / #4382 Merged Skip automatic memory for sessions DSH classifies as derived Classifies by session origin, not by the directory the session runs in
#6742 / #6762 Open Do not create an empty session before the first captured message About ordering inside a participating session
#5336 Closed MCP proxy sent the boot directory's peer instead of the session's Same class of bug — per-session state lags the boot directory — already fixed for the peer; the other knobs still lag
#7395 / #7402 Open Per-workspace connection config Credentials, not behaviour
#7378 Open Select connection by working directory Same, connection layer
Discussion #4565 — Introduced the workspace files and schema v1 Its v1 key set has no master switch
Proposed Solution

Make the dsh plugin resolve the whole configuration per session from
session.header.cwd, and expose the master switch as a workspace key:

{
  "version": 1,
  "enabled": false
}

With that file in place, every session running in the directory creates no
OpenViking session, injects no profile, recalls nothing, captures nothing, commits
nothing, and issues no request to the server — initializeState() returns before
the health probe. Sessions in other directories on the same runtime keep working.
enabled: false is announced at session start by the existing
announcedOverrides() rule, and OPENVIKING_MEMORY_ENABLED=0 still outranks a
workspace file.

Implemented in #7482, which also fixes the per-session resolution, so
recall.enabled and capture.enabled start working as documented.

Alternatives Considered
  • Add a separate bypass.session_patterns entry for the directory. It exists,
    but it only filters recall/capture at the hook stage; it does not stop session
    creation or profile injection, and it is a list of globs rather than a property
    of the workspace.
  • Use OPENVIKING_MEMORY_ENABLED=0. This is process-wide: it would also switch
    memory off for every other workspace served by the same dsh web.
  • Separate profile per workspace. Works, but the workspace switch is the
    mechanism the configuration file already promises.
Feature Area

Model Integration

Lingua principale
Python
Stelle
41.8k
Fork
3.4k
Merge medio
19h 29m
PR unite (30g)
500

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di volcengine/OpenViking

Tutte le issue di volcengine/OpenViking

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.