Bug Description
Issue
lola install edits files I maintain by hand and that every assistant reloads on every turn: CLAUDE.md, AGENTS.md, GEMINI.md, etc... . It takes the module's whole AGENTS.md and inlines it into a managed block. No flag asks first, and it will do the same to the global ~/.claude/CLAUDE.md, which then follows me into every unrelated project (and is possibly duplicitive).
I noticed it because my ~/.claude/CLAUDE.md had picked up material from modules I installed at user scope. Most of those lines aren't useful at the global level. Claude Code already finds skills on its own from ~/.claude/skills/, and the skillsaw block is that project's build checklist, which isn't relevant to my global context.
Lola does render per-assistant, and the Cursor target takes a clean approach: it writes instructions to a dedicated .cursor/rules/<module>-instructions.mdc that it owns and can delete cleanly. The claude-code, opencode, and gemini targets route instructions straight into the shared, user-authored file through ManagedInstructionsTarget, gated only by "did the module ship an AGENTS.md?". Ideally a package manager writes its own artifacts into its own namespaces rather than touching a file that affects literally all of my work.
There is a partial option already: --append-context writes a reference instead of inlining. Inlining is still the default, though, and there's no way to opt out of context-file changes entirely. I also checked whether I could filter on my end: neither Claude Code nor OpenCode lets a hook strip already-loaded context, so the fix needs to live in Lola.
Desired Resolution
Instruction injection should be opt-in (least surprise) and off by default. A plain lola install would touch only expected targets and leave the context files alone unless asked, via a --with-instructions flag or a config key, recorded so update keeps honoring the choice.
Two possible follow-ups once that's in place. The global home files could require a separate, explicit opt-in, since a module's instructions are project-relative by nature. And when instructions genuinely are wanted, it might be worth copying the Cursor approach: write a dedicated, removable file (Claude Code can pull it in with @import) instead of inlining, or at least keep the shared block down to a compact name + one-line-description index instead of the full body.
apm-cli (Microsoft's Agent Package Manager) has some prior art here. Writing context files is an explicit apm compile step, --target picks which files get written, and for Claude it emits @apm_modules/... references instead of inlining the full content.
Steps to Reproduce
lola install <module-with-an-AGENTS.md> --scope user -a claude-code, then look at the lola: markers in ~/.claude/CLAUDE.md
Component
Module management
Lola Version
No response
Python Version
No response
Operating System
No response
Logs and Error Messages
Additional Context
No response
Bug Description
Issue
lola installedits files I maintain by hand and that every assistant reloads on every turn:CLAUDE.md,AGENTS.md,GEMINI.md, etc... . It takes the module's wholeAGENTS.mdand inlines it into a managed block. No flag asks first, and it will do the same to the global~/.claude/CLAUDE.md, which then follows me into every unrelated project (and is possibly duplicitive).I noticed it because my
~/.claude/CLAUDE.mdhad picked up material from modules I installed atuserscope. Most of those lines aren't useful at the global level. Claude Code already finds skills on its own from~/.claude/skills/, and the skillsaw block is that project's build checklist, which isn't relevant to my global context.Lola does render per-assistant, and the Cursor target takes a clean approach: it writes instructions to a dedicated
.cursor/rules/<module>-instructions.mdcthat it owns and can delete cleanly. The claude-code, opencode, and gemini targets route instructions straight into the shared, user-authored file throughManagedInstructionsTarget, gated only by "did the module ship an AGENTS.md?". Ideally a package manager writes its own artifacts into its own namespaces rather than touching a file that affects literally all of my work.There is a partial option already:
--append-contextwrites a reference instead of inlining. Inlining is still the default, though, and there's no way to opt out of context-file changes entirely. I also checked whether I could filter on my end: neither Claude Code nor OpenCode lets a hook strip already-loaded context, so the fix needs to live in Lola.Desired Resolution
Instruction injection should be opt-in (least surprise) and off by default. A plain
lola installwould touch only expected targets and leave the context files alone unless asked, via a--with-instructionsflag or a config key, recorded soupdatekeeps honoring the choice.Two possible follow-ups once that's in place. The global home files could require a separate, explicit opt-in, since a module's instructions are project-relative by nature. And when instructions genuinely are wanted, it might be worth copying the Cursor approach: write a dedicated, removable file (Claude Code can pull it in with
@import) instead of inlining, or at least keep the shared block down to a compact name + one-line-description index instead of the full body.apm-cli (Microsoft's Agent Package Manager) has some prior art here. Writing context files is an explicit
apm compilestep,--targetpicks which files get written, and for Claude it emits@apm_modules/...references instead of inlining the full content.Steps to Reproduce
lola install <module-with-an-AGENTS.md> --scope user -a claude-code, then look at thelola:markers in~/.claude/CLAUDE.mdComponent
Module management
Lola Version
No response
Python Version
No response
Operating System
No response
Logs and Error Messages
Additional Context
No response