Agent no follow rules after compact session

I have a Gitops project with Fluxcd used in two Kubernetes clusters. I can't allow the agent to commit and push to GitHub without manual review first, as this could lead to something going wrong and compromising the production infrastructure.
I have an explicit rule prohibiting commit+push, and this works fine until the session is compacted and a new session starts.
It seems that after compaction, the rules are lost. I believe a safer approach would be to compact the conversation and include the user-defined rules in their entirety in the new context after compaction. Otherwise, it poses a significant risk in some use cases.

I have some rules in an AGENTS.md file and also in a custom agent called coder.

This seems like a bug, or at least a shortcoming, in the current workflow.

Is there a way I can explicitly configure it somewhere to ALWAYS include the agent contents and local settings after compaction?

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

Session automatically compacted, destroying the entire working context #2945: Session automatically compacted, destroying the entire working context - Reports that compaction causes the agent to forget everything about the session
Model in BUILD mode does not have enough context to continue after compaction #3031: Model in BUILD mode does not have enough context to continue after compaction - Specifically mentions suspicion that AGENTS.md is not included in context after compaction, which directly relates to your issue with rules being lost
Soft compaction / AI global workspace metabolism #3032: Soft compaction / AI global workspace metabolism - Discusses how current compaction replaces entire context with brief summary, losing AI assistant "personality" and requiring re-feeding of nuances

Feel free to ignore if none of these address your specific case about GitOps rules and commit/push restrictions being lost after compaction.

I see some opportunities for improvement in the current compact solution.

Introduce a new RulesPart type to preserve AGENTS.md rules across summarization:

When constructing the context to send to the LLM in createUserMessage(), we can introduce a new RulesPart type with a pinned field. If it's the first message, it will be marked as part.type = "rules" and pinned: true (the first message in the context contains critical instructions for LLM's attention). The summary for LLM would always preserve pinned rules + msgs.slice(i).

In summarize.txt, include preserve custom rules and maintain agent-specific constraints.
It would look like this:

You are a helpful AI assistant tasked with summarizing conversations.

When asked to summarize, provide a detailed but concise summary of the conversation.
Focus on information that would be helpful for continuing the conversation, including:
  - What was done
  - What is currently being worked on
  - Which files are being modified
  - What needs to be done next
+ - Preserve custom rules from AGENTS.md
+ - Maintain agent-specific constraints

I'm doing some testing on a local fork.

Something like this:

// New RulesPart type in message-v2.ts:
export const RulesPart = PartBase.extend({
  type: z.literal("rules"),
  rules: z.string(),
  source: z.enum(["AGENTS.md", "custom-agent", "user-instruction"]),
  pinned: z.boolean().default(true),
  hash: z.string(),
}).meta({
  ref: "RulesPart",
})
export type RulesPart = z.infer<typeof RulesPart>

// Enhanced filterSummarized() (message-v2.ts):
export function filterSummarized(msgs: { info: MessageV2.Info; parts: MessageV2.Part[] }[]) {
  const i = msgs.findLastIndex((m) => m.info.role === "assistant" && !!m.info.summary)
  if (i === -1) return msgs.slice()

  // Extract messages before the last summary that contain pinned rules
  const pinnedRulesMessages = msgs
    .slice(0, i)
    .filter((msg) => msg.parts.some((part) => part.type === "rules" && part.pinned))

  // Return: pinned rules messages + all messages from summary onwards
  return [...pinnedRulesMessages, ...msgs.slice(i)]
}

. I can't allow the agent to commit and push to GitHub without manual review first,

ill dig into this to double check AGENTS.md is being persisted, but is this problem not better suited for permissions?

@524c can;t you do this in global opencode config? (this is copied from my config that's why rm is in there )

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "rm *": "ask",
      "git push *": "ask",
      "git commit *": "ask",
    },
  },
}

@524c can;t you do this in global opencode config? (this is copied from my config that's why rm is in there )
{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "rm *": "ask",
      "git push *": "ask",
      "git commit *": "ask",
    },
  },
}

Good point, I'll try to work more on permissions. This restriction, specifically for git push, is due to the gitops nature of some projects. In other cases, it's not a problem for agent/llm to bypass a rule and perform a git push.

With the modifications I made to my fork, after a 3 hours session and many compactions I noticed a significant improvement in the agent's behavior, due to forcing the first message with an uncompressed rich context.

@524c can;t you do this in global opencode config? (this is copied from my config that's why rm is in there )
{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "rm *": "ask",
      "git push *": "ask",
      "git commit *": "ask",
    },
  },
}

But for now, I'm just thinking out loud. It was just an idea I wanted to share. I'll continue doing more local testing.
You can close the issue if you prefer 🙃

ill do a glance over code and some simple test cases just to make sure everything behaves correctly before closing!

I analyzed the code further and saw that AGENTS.md is injected via the system prompt.

But my empirical experience has shown me that injecting the AGENTS.md into the conversion yields better results. My thoughts on this behavior are:

Session starts => AGENTS.md at system prompt
User: "Don't commit"
Agent: "Understood, I won't commit/push"
[Multiple tasks...]
SUMMARY => Removes these acknowledgements
System prompt still has AGENTS.md BUT conversation has lost its "active contract"

With RulesPart pinned:
• Rules SURVIVE explicit summarization
• Remain visible as part of the conversation's "active contract"

LLMs can treat these two types differently:

• System Prompt: "These are background instructions"
• Conversational Messages: "This is what we are actively discussing and following"

After multiple summarizations, the system prompt can become "invisible infrastructure" while pinned messages remain conversation are treated as "active explicit agreements".

yeah i see what u mean

i think the simple fix for now is just tell the compact prompt to preserve instructions/rules the user set during convo

i think the simple fix for now is just tell the compact prompt to preserve instructions/rules the user set during convo

Yes, I think it can help a lot.
Something like this in the summary prompt:

including:
 - What was done
 - What is currently being worked on
 - Which files are being modified
 - What needs to be done next
+- Preserve custom rules from AGENTS.md
+- Maintain agent-specific constraints and deletion protection rules

I'll continue testing these two approaches:

just improving the summary prompt
injecting AGENTS.md into the conversation and removing it from the system prompt.

With these two approaches, my Opencode fork now strictly follows the instructions in my AGENTS.md, which tell it to only run git push after explicit authorization.

It always asks for permission now, even after a long session of 8+ hours and dozens of conversation compactions/summaries 🙌

I could even block this through permissions, but that would still be trying to plug a leak.

injecting AGENTS.md into the conversation and removing it from the system prompt.

I don't think we wanna do this one but the other one sounds good

Thanks, updating the summary prompt will help a lot.

Hello. Jumping into this beautiful conversation, I totally subscribe to the sentiment here. I even added a rule in my agents.md that should the session get compacted, it must generate a section to remind itself of the rules in the new one, and that doesn't work either. So indeed I have found the permissions section which will avoid some disasters, and I have to say that the permissions section for bash and so on is superb. But still, it'd be great to have a hook for "on_compact" or something of that description. Thanks !

I agree this would be more than a nice to have.

In my case I would like to let work agent on some quite long tasks and I very often fall into the issue of full token auto compaction with basic rules and guidance are lost.

I would really appreciate a system with a magic file (say ON_COMPACT_RULES.md) is read by default on each compaction if it exists. this would not break existing behavior, but let users like me and other in this conversation, put a list of basic rules, doc references, point context for current long task and get much more out of our tokens per full context fill.

Indeed, I think this simple feature could help me (and other) save A LOT of token every day.

However I thing reread AGENTS.md is not a good idea. The idea for me is really to get a mechanic to follow a "single long temp task"

I also think this can be a quite simple quick win to implement (from my naive point of views :) )

I am having a similar issue and solved it by making a plugin that makes a session management tool, not only I control the message that gets passed after compacting but also can make a different primary agent to take over, pair it with some smart prompting and you can have some really interesting workflows, I have it in my workflows to trigger compaction at certain points, I let the agent write whatever message it want to tell itself and that message would be passed on after the compaction (potentially to another agent), it has more features like forking as well, please check it out and give me some feedback opencode-sessions

Just sharing another related place where this shows up - I have a similar instruction to not commit and I use the github action. And if the action compacts - it actually commits the changes and then the github action does not consider changes dirty and skips the PR creation process

@rohit-gohri

@rohit-gohri and this instruction is directly in AGENTS.md? It isn't in other files?

@rohit-gohri

@rohit-gohri and this instruction is directly in AGENTS.md? It isn't in other files?

It was actually in the github issue content that triggers the action

I would be curious if #4556 solves your issue which is in 1.0.86

I would be curious if #4556 solves your issue which is in 1.0.86

I was using a fork until now. I'm going to install this version and I plan to use it a lot over the weekend, so I'll provide feedback. Thank you.

I would be curious if #4556 solves your issue which is in 1.0.86

I didn't have any problems today during my use that would cause the agent to lose context and commit/push against an explicit order, which is something very serious to me.

Thank you.

I would still like to have this in opencode/src/session/prompt/summarize.txt, if possible:

+ - Preserve custom rules from AGENTS.md
+ - Maintain agent-specific constraints

Or perhaps allow customization of the prompts?

@TheMorpheus407

Issue #3099 — Research

Hey @TheMorpheus407,

They completely ignored what I said, so I closed the issue a long time ago. It's irrelevant to me right now because I use other agents who are much more reliable.

Navigation Menu

Repository navigation

Agent no follow rules after compact session #3099

Issue #3099 — Research

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Agent no follow rules after compact session #3099

Description

Activity

github-actions commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

rekram1-node commented on Oct 11, 2025

0x524c commented on Oct 11, 2025

JohnPreston commented on Oct 23, 2025

eregnier commented on Oct 29, 2025

malhashemi commented on Oct 30, 2025

rohit-gohri commented on Oct 31, 2025

rekram1-node commented on Oct 31, 2025

rohit-gohri commented on Oct 31, 2025

wolfie82 commented on Nov 21, 2025

0x524c commented on Nov 21, 2025

0x524c commented on Nov 23, 2025

0x524c commented on Jun 8, 2026

Issue #3099 — Research

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions