Feature: disable memory injection for specific subagents

[zedd3v]

https://github.com/alvinunreal/oh-my-opencode-slim
When using the @council subagent I do not want anything injected into the master subcouncillors

[ualtinok]

Memory is not injected for subagents at all already. Current primary, subagent matrix:

Feature	Primary + ctx_reduce_enabled: true	Primary + ctx_reduce_enabled: false	Subagents (any ctx_reduce_enabled)
Tag DB records	✓	✓	✓
§N§ tag prefix injection in message text	✓	✗	✗
ctx_reduce tool	✓	✗	✗
Historian / compartments / compressor	✓	✓	✗
Compartment injection (<session-history>)	✓	✓	✗
<project-docs>, <user-profile>, <key-files> system-prompt blocks	✓	✓	✗
Rolling / tool-heavy / sticky / deferred-note nudges	✓	✗	✗
Heuristic tool drops at execute threshold	✓	✓	✓
Heuristic reasoning clearing	✓	✓	✓
85 % force-materialization	✓	✓	✗
95 % block + emergency recovery	✓	✓	✗
Experimental age-tier caveman text compression	✗	opt-in	✗

[zedd3v]

@ualtinok the main orchestrator injects the memory when it forms the subagent prompt

[dhaern]

Memory is not injected for subagents at all already. Current primary, subagent matrix:

Feature Primary + ctx_reduce_enabled: true Primary + ctx_reduce_enabled: false Subagents (any ctx_reduce_enabled)
Tag DB records ✓ ✓ ✓
§N§ tag prefix injection in message text ✓ ✗ ✗
ctx_reduce tool ✓ ✗ ✗
Historian / compartments / compressor ✓ ✓ ✗
Compartment injection (<session-history>) ✓ ✓ ✗
<project-docs>, <user-profile>, <key-files> system-prompt blocks ✓ ✓ ✗
Rolling / tool-heavy / sticky / deferred-note nudges ✓ ✗ ✗
Heuristic tool drops at execute threshold ✓ ✓ ✓
Heuristic reasoning clearing ✓ ✓ ✓
85 % force-materialization ✓ ✓ ✗
95 % block + emergency recovery ✓ ✓ ✗
Experimental age-tier caveman text compression ✗ opt-in ✗

I think this issue was closed too narrowly.
Response is correct only for direct Magic Context injection inside subagent sessions. In 0.15.2, child sessions are marked as subagents via parentID, and the full feature path is disabled for them, so <session-history> / project memory injection does not run directly inside those sessions.

However, that does not cover the problem reported here.

With oh-my-opencode-slim council, the parent/council agent can receive Magic Context injected material in its own context, then pass it downstream as normal prompt text when creating councillor sessions.

Evidence from slim:

const session = await this.client.session.create({
  body: {
    parentID: options.parentSessionId,
    title: options.title,
  },
  query: { directory: this.directory },
});
const body: PromptBody = {
  agent: options.agent,
  model: modelRef,
  tools: { task: false },
  parts: [{ type: 'text', text: options.promptText }],
};

Council/councillor fanout makes this especially visible, because the council agent forwards prompt text to multiple internal child sessions.t includes in options.promptText still reaches the councillor as ordinary user prompt content.
That means the practical issue is real:

• Direct subagent injection: already disabled.
• Parent-to-subagent propagation: still possible.
• Council/councillor fanout makes this especially visible, because the council agent forwards prompt text to multiple internal child sessions.

A fix would probably need one of these:

1. Allow disabling Magic Context memory/session-history injection for specific agents, e.g.

{
  "memory": {
    "exclude_agents": ["council"]
  }
}

or more generally:

{
  "injection": {
    "exclude_agents": ["council"]
  }
}

2. Mark injected blocks as non-forwardable and provide guidance/tools to strip them before delegation.
3. Add a special case for fanout agents such as council, where injected memory should not be included because it may be propagated to internal councillors.

So I agree that Magic Context is not directly injecting into subagents, but the reported leak path is still valid through parent prompt construction/forwarding.

@ualtinok

[ualtinok]

I think I didn't understand? Is the problem a primary agent passing its memory to subagents via memory? Council in omo-slim is derivation of athena (code-yeongyu/oh-my-openagent#1821) which I'm using extensively in my own omo fork and I didn't have this issue. If primary agent is passing memory to the downstream subagent's I don't think Magic Context should have a say on this?

Please elaborate, thanks

[dhaern]

I think I didn't understand? Is the problem a primary agent passing its memory to subagents via memory? Council in omo-slim is derivation of athena (code-yeongyu/oh-my-openagent#1821) which I'm using extensively in my own omo fork and I didn't have this issue. If primary agent is passing memory to the downstream subagent's I don't think Magic Context should have a say on this?

Please elaborate, thanks

Thanks, I think the confusion is around what I meant by "leak".

I agree Magic Context is not directly injecting <session-history> / memory inside subagent sessions. The subagent guard via parentID works for that path.

The issue I was describing is different: council-style agents act as fanout orchestrators. The primary/council agent receives Magic Context injected context in its own prompt, and then constructs normal text prompts for downstream councillor sessions. At that point the Magic Context content is no longer "Magic Context injection" from the child session perspective; it is just ordinary prompt text forwarded by the parent agent.

So the distinction is:

• Direct Magic Context injection into councillor/subagent session: not happening, already disabled.
• Parent/council prompt forwarding injected context as plain text: can still happen.

I agree this may not be something Magic Context can fully control once the parent agent decides to forward its prompt/context. But for council/fanout agents it can be problematic because the same injected history/memory may be copied into multiple councillor prompts, increasing token use and possibly biasing independent reviewers.

What I was suggesting is not necessarily that Magic Context should police all downstream prompts, but that it could provide a config-level escape hatch for primary agents that are known to fan out, e.g.:

{
  "injection": {
    "exclude_agents": ["council"]
  }
}

or maybe other more complex and elegant solution.

That would let users disable Magic Context injection for orchestrator/fanout agents while keeping it enabled for normal primary sessions.

So: yes, the current subagent guard is correct; the remaining concern is parent-to-child propagation by council-style agents.

[ualtinok]

Okay, you actually meant you want to disable memory injection for a specific primary agent.

The original design of council orchestration which omo-slim took it from is here (code-yeongyu/oh-my-openagent#1821), which I made long ago and using extensively since on my own fork. (which is drifted quite a lot from omo now).

I now see "council" is a primary agent and corresponds to Athena in original PR. I think it's viable to have what you're asking but I wonder if we disable injection for a specific agent, will we also want to disable some other functionality like ctx_memory or historian fully etc.

To be honest since magic-context I never used Athena directly (council) but always ask my main agent for the project to run a council via athena-junior. (which itself is a subagent that convenes the council). And I'd recommend that also.

I'll think about a cleaner solution about this, let me know your thoughts also.

[dhaern]

Okay, you actually meant you want to disable memory injection for a specific primary agent.

The original design of council orchestration which omo-slim took it from is here (code-yeongyu/oh-my-openagent#1821), which I made long ago and using extensively since on my own fork. (which is drifted quite a lot from omo now).

I now see "council" is a primary agent and corresponds to Athena in original PR. I think it's viable to have what you're asking but I wonder if we disable injection for a specific agent, will we also want to disable some other functionality like ctx_memory or historian fully etc.

To be honest since magic-context I never used Athena directly (council) but always ask my main agent for the project to run a council via athena-junior. (which itself is a subagent that convenes the council). And I'd recommend that also.

I'll think about a cleaner solution about this, let me know your thoughts also.

Yeah, exactly — I meant the primary council agent, not the councillor subagents directly.

I don’t think it necessarily needs to disable everything like ctx_memory or historian globally. The main thing I’m worried about is automatic injected context/memories/compartments getting into the primary council prompt, because then the council can pass that context down to councillors and the “independent review” gets noisier / less clean.

So maybe the cleaner option is something like a per-agent injection exclude list, e.g.

memory: {
  injection_exclude_agents: ["council"]
}

or more generally excluding certain primary agents from automatic context injection. I’d still be fine with manual ctx_search / ctx_memory tools existing if the agent explicitly uses them; I just don’t want automatic injected project memory/history in that specific primary agent.

Your Athena/Athena-junior setup makes sense. In omo-slim/OpenCode though, council is exposed as a primary agent and it’s pretty natural to call it directly, so having a guard for that case would be useful.

No rush — I mainly wanted to clarify the exact problem. Btw this plugin is amazing and much better than https://github.com/Opencode-DCP/opencode-dynamic-context-pruning congratz.

[ualtinok]

Same fix as #53 — shipped in v0.16.2.

For your council case: the council agent in oh-my-opencode-slim has a distinctive opener you can match directly without modifying its prompt:

"system_prompt_injection": {
    "enabled": true,
    "skip_signatures": [
        "You are the Council agent — a multi-LLM"
    ]
}

That string is already in the slim council agent's system prompt, so the council orchestrator turn now gets no ## Magic Context block, no project docs, no user profile, no key files. The councillor subagents are subagents (not primary), so they were never receiving full feature injection anyway — only the council primary agent itself was the issue.

This keeps ctx_memory and ctx_search available as tools (in case any downstream consumer ever wants to use them), and historian still runs in the background. It just stops the automatic injected context from polluting the council's own prompt → councillor message bridge.

Upgrade with:

bunx --bun @cortexkit/magic-context@latest doctor --force

Closing — please reopen if you still see injected memories in the council's prompt on v0.16.2.