[FEATURE]: Compaction loses AGENTS.md/CLAUDE.md instruction context #16960

Activity

1. github-actions

   assigned

   rekram1-node

   on Mar 11, 2026
2. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on Mar 11, 2026
3. github-actions commented on Mar 11, 2026

   

   github-actionsBot

   on Mar 11, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue doesn't fully meet our contributing guidelines.

   What needs to be fixed:

   • The issue uses the Feature Request template but the title is missing the required [FEATURE]: prefix. Please rename the title to start with [FEATURE]:.

   Please edit this issue to address the above within 2 hours, or it will be automatically closed.

   ---

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Improve compaction prompt to preserve critical context details #16512: Improve compaction prompt to preserve critical context details — very similar request to preserve instruction/constraint context through compaction
   • Auto-compaction causes the subagent to lose its original context, possibly the system prompt as well #6535: Auto-compaction causes the subagent to lose its original context, possibly the system prompt as well — same root symptom
   • [FEATURE]: Allow pinning important instructions/messages per session to keep them after compaction. #8932: Allow pinning important instructions/messages per session to keep them after compaction — same underlying need

   If you believe this was flagged incorrectly, please let a maintainer know.
4. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Mar 11, 2026
5. jblenman

   changed the title [-]Compaction loses AGENTS.md/CLAUDE.md instruction context[/-] [+][FEATURE]: Compaction loses AGENTS.md/CLAUDE.md instruction context[/+] on Mar 11, 2026
6. github-actions

   removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Mar 11, 2026
7. github-actions commented on Mar 11, 2026

   

   github-actionsBot

   on Mar 11, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue title with the [FEATURE]: prefix! The issue now meets our contributing guidelines. We appreciate the clear description, steps to reproduce, and environment info.
8. QuantumEdu commented on Apr 10, 2026

   

   QuantumEdu

   on Apr 10, 2026

   More actions

   Comment for Issue #16960 (Compaction loses instruction context)

   This is a critical bug that undermines the value of project-specific instructions. A structured approach to preserving instruction context during compaction could solve this:

   Proposed Solution: Instruction-Aware Compaction

   Before compacting, capture the instruction context structure:

   ## Instruction Context Snapshot
   
   ### Project Instructions
   - Files loaded: PROJECT.md, AGENTS.md, .opencode/stack_config.json
   - Key rules:
     - Git safety: [rule description]
     - Coding conventions: [rule description]
     - Naming patterns: [rule description]
     - Tag taxonomy: [rule description]
   
   ### Active Constraints
   - Thresholds: text > 1000 words → ask, tasks > 90 min → split
   - Failsafes: structural conflict → log, data loss risk → stop
   - Forbidden actions: [list]
   
   ### User Preferences Discovered
   - [Preferences learned during session]

   Session Summary Format (Mandatory Before Compaction)

   ## Goal
   [What was being worked on]
   
   ## Instructions
   [Project rules and user preferences that must persist]
   
   ## Discoveries
   - Technical findings, gotchas, non-obvious learnings
   
   ## Accomplished
   - Completed items with key details
   
   ## Next Steps
   - What remains for next session
   
   ## Relevant Files
   - path/to/file — [what changed/role]
   

   Implementation Approach

   1. Extract instruction context before compaction:

      • Parse all project instruction files
      • Identify active rules and constraints
      • Capture user preferences learned during session

   2. Include in compaction prompt:

      • Add instruction context as system message
      • Require summary to reference preserved instructions

   3. Restore after compaction:

      • Re-inject instruction context into system prompt
      • Verify agent still follows original rules

   Trade-offs

   • Context size: Instruction context adds tokens, but losing rules is worse
   • Dynamic rules: Some rules are learned during session — need capture mechanism
   • Validation: Should verify agent behavior post-compaction matches pre-compaction

   This approach ensures that critical project rules (git safety, coding conventions, naming patterns) survive compaction, preventing agents from becoming "literal" and ignoring important constraints.
9. thdxr

   removed

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on May 3, 2026
10. Txikivasco commented on Jun 2, 2026

    

    Txikivasco

    on Jun 2, 2026

    More actions

    Still not solved as of today (02-june-2026). bumping this thread in case someone is willing to check it. This makes the agent lose project specific instructions. It's critical to solve it.

    👍React with 👍5Reacted by Taimoor Khan, hkalbasi, Link, finduspedersen and Derek Baron
11. hkalbasi commented on Jun 8, 2026

    

    hkalbasi

    on Jun 8, 2026

    More actions

    The compact implementation is actually awful, compared to other harnesses like copilot and codex. In addition to keeping AGENTS.md, it should also keep certain files that the agent feels useful for the next task.

    👍React with 👍3Reacted by Sergey Kostrukov, finduspedersen and Derek Baron
12. github-actions commented on Aug 8, 2026

    

    github-actionsBot

    on Aug 8, 2026 – with GitHub Actions

    Contributor

    More actions

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
13. github-actions

    closed this as not plannedon Aug 8, 2026
14. em commented on Aug 26, 2026

    

    em

    on Aug 26, 2026

    Last edited by em

    More actions

    Is this actually confirmed as a real issue and/or fixed? In v2 specifically.

    I'm really having trouble understanding the issue tracking around this. In particular, issues like this that describe a clear catastrophic failure of compaction appear to be getting closed by a bot as "not planned".

    Either it is confirmed and compaction is entirely broken in all conceivable ways, or it's not reproduced and not a real issue and something else is happening. Not planned auto-closing doesn't make sense here.

    I'm seeing behavior where, after compaction, the agent appears to have completely forgotten its own definition. It looks as though the agent definition that was present during initialization is not included in the post-compaction context.

    If that is actually happening, this isn't a minor context-loss bug. It means the agent can lose the instructions that define what the agent is, what it is supposed to do, and how it is supposed to behave. That would make the compaction mechanism fundamentally incorrect.

    The expected semantics of compaction seem unambiguous:

    Initial agent context + session history → compaction → initial agent context + compacted representation of the session

    The agent's definition is initialization context, not disposable conversation history. It therefore needs to remain present after compaction. Otherwise the resulting context is not equivalent to a compacted continuation of the original session; it is a differently initialized agent with a summary of the previous conversation.

    So... is this issue real or not? If it's real how is it any other work is done on anything other than fixing what amounts to entirely functionally incorrect and broken?

    Some clarification on the actual status of this from the developers would be much appreciated. A closed as "not a bug" would make much more sense here if it's not a bug. Or if it is a bug, I think anyone would agree it's a p0 and open.

    I guess in general I'd really appreciate if opencode could improve its process / issue tracking. Every time I have issues I seem to find something related that got closed as not planned like this. Makes it really hard to know what is an open issue that needs a workaround if there's no real tracking just auto closed stuff into a general bucket of "not planned".

    I understand it's an open source volunteer project and kudos on all the amazing work, but the issue tracking being better would really be nice so the users can eagerly await the fixes knowing it is a bug or not, and find some workaround in the meantime. It's all guessing now and having your ai dig through the source to try and figure out the real state of things.