Tag accumulation bug: stripTagPrefix only removes single tag causing excessive §N§ repetition

[tomolom]

Bug Description

The stripTagPrefix function in packages/plugin/src/hooks/magic-context/tag-content-primitives.ts only strips a single tag prefix, but the transform pipeline can process the same content multiple times (e.g., during compartment compaction, message replay, or transform re-runs). This causes tags to accumulate, leading to unreadable messages with excessive §N§ symbols like:

§4687§ §4687§ §4687§ §4687§ ... §4687§ actual content

Root Cause

const TAG_PREFIX_REGEX = /^§\d+§\s*/;  // No global flag, only matches ONE tag

export function stripTagPrefix(value: string): string {
  return value.replace(TAG_PREFIX_REGEX, "");  // Only strips first tag!
}

export function prependTag(tagId: number, value: string): string {
  const stripped = stripTagPrefix(value);  // Still has old tags
  return `§${tagId}§ ${stripped}`;  // Prepends new tag to remaining tags
}

Each transform pass:

1. Calls prependTag() which strips only the outermost tag
2. Leaves previously accumulated tags intact
3. Prepends a new tag on top
4. Result: tag stack grows unbounded

Proposed Fix

Change the regex to match all consecutive tags at the start:

const TAG_PREFIX_REGEX = /^(?:§\d+§\s*)+/;  // Match one or more tags

export function stripTagPrefix(value: string): string {
  return value.replace(TAG_PREFIX_REGEX, "");
}

This ensures stripTagPrefix removes all accumulated tags, so prependTag always results in exactly one tag as intended.

Impact

• Messages become increasingly difficult to read as tags accumulate
• Affects long-running sessions or those with frequent compartment operations
• No data loss, but severe UX degradation

[ualtinok]

Thanks for the report and PR — we merged #12 as a defensive hardening measure.

After investigating, we confirmed that the prependTag → stripTagPrefix cycle doesn't actually cause tag accumulation on its own, since prependTag always strips the existing tag before prepending a new one. The count stays at 1 across transform passes.

The real source of doubled §N§ prefixes is LLM mimicry — the model sees tag-prefixed content in its context and sometimes reproduces the pattern in its own output. We found multiple examples in our production database where assistant responses start with copied §N§ tags (e.g., §129§ Launched as athena-junior..., §134§ Still running...). On the next transform pass, tagMessages strips the one LLM-copied tag and prepends the real one, so it self-heals to a single tag. But if the LLM copies multiple tags in one output, the old regex would only strip the outermost — which is exactly what your fix addresses.

We could strip LLM-copied tags from the stored assistant response, but that would require mutating the previous assistant message on the next transform pass, which busts the prompt cache for everything after that message. Cache preservation is a core design constraint of the plugin, so we prefer the defensive regex approach you implemented — it handles the symptom cleanly without cache cost.

We already have anti-hallucination guidance in the agent prompt warning against copying §N§ patterns, but models don't always respect it. Your fix is the right safety net. Thanks again for the contribution!