Greptile Summary

This PR adds an opt-in agents.defaults.contextInjection configuration setting that allows workspace bootstrap files (AGENTS.md, SOUL.md, etc.) to be skipped on continuation turns, addressing a reported ~93% token waste on long sessions. The default remains "always" (existing behavior), while "continuation-skip" skips injection when the session file already exists.

Key aspects of the implementation:

• Compaction-safe: compact.ts calls resolveBootstrapContextForRun() directly without the continuation-skip guard, so context is always re-injected after a compaction event.
• Correct session detection: uses a single fs.stat(params.sessionFile) ahead of bootstrap resolution; this is deliberately separate from the pre-existing hadSessionFile check (which runs after repairSessionFileIfNeeded and serves a different purpose).
• Well-tested: 8 new tests covering the helper function and Zod schema validation.
• Two minor style nits: (1) contextInjection in AgentDefaultsConfig repeats the inline union "always" | "continuation-skip" instead of reusing the AgentContextInjection alias defined two lines above in the same file; (2) a blank line is missing between resolveContextInjectionMode and the following BootstrapContextRunKind type in bootstrap-files.ts.

Confidence Score: 5/5

Safe to merge — opt-in with a no-op default, compaction path verified, and tests cover the key edge cases.

The change is strictly additive and opt-in (default 'always' preserves existing behavior). The compaction-safety claim is verified: compact.ts calls resolveBootstrapContextForRun independently. Session-file detection logic is correct. The only findings are two minor style issues that don't affect correctness or reliability.

No files require special attention.

This is a comment left during a code review.
Path: src/config/types.agent-defaults.ts
Line: 150

Comment:
**Use `AgentContextInjection` instead of inline union**

`AgentContextInjection` is exported from the same file at line 11 specifically to represent this type. The `contextInjection` field in `AgentDefaultsConfig` should reference it rather than repeating the inline union, so future additions to the allowed values only need to be made in one place.

```suggestion
  contextInjection?: AgentContextInjection;
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/agents/bootstrap-files.ts
Line: 22-23

Comment:
**Missing blank line after function declaration**

A blank line is missing between the closing brace of `resolveContextInjectionMode` and the `BootstrapContextRunKind` type declaration, breaking the visual separation that exists between all other top-level declarations in this file.

```suggestion
}

export type BootstrapContextRunKind = "default" | "heartbeat" | "cron";
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "perf(agents): add contextInjection optio..." | Re-trigger Greptile}

🔒 Aisle Security Analysis

We found 2 potential security issue(s) in this PR:

content = await fs.readFile(sessionFile, "utf-8");
...
for (const line of content.split(/\r?\n/)) {
  ...
}

import fs from "node:fs";
import readline from "node:readline";

export async function hasCompletedBootstrapTurn(sessionFile: string): Promise<boolean> {
  try {
    const stream = fs.createReadStream(sessionFile, { encoding: "utf8" });
    const rl = readline.createInterface({ input: stream, crlfDelay: Infinity });

    let hasAssistant = false;
    let compactedAfterLastAssistant = false;

    for await (const line of rl) {
      if (!line) continue;
      ​// same parsing logic...
    }
    return hasAssistant && !compactedAfterLastAssistant;
  } catch {
    return false;
  }
}

const { bootstrapFiles: hookAdjustedBootstrapFiles, contextFiles } = isContinuationTurn
  ? {
      bootstrapFiles: [] as WorkspaceBootstrapFile[],
      contextFiles: [] as EmbeddedContextFile[],
    }
  : await resolveBootstrapContextForRun({ ... });

const minimalRun = await resolveBootstrapContextForRun({
  ...,
  contextMode: "lightweight",
  runKind: params.bootstrapContextRunKind,
});
​// or explicitly filter to required filenames before buildBootstrapContextFiles

Analyzed PR: #55221 at commit 3ee8918

_{Last updated on: 2026-03-27T04:04:21Z}

Thanks for the analysis @aisle-research-bot.

Addressing the security concern:

1. This is opt-in — default is "always" (no behavior change). Users must deliberately set contextInjection: "continuation-skip" to enable it.

2. Pre-existing precedent — the codebase already has two mechanisms that produce the same effect:

   • skipBootstrap: true drops all bootstrap files entirely
   • bootstrapContextMode: "lightweight" returns empty context for non-heartbeat runs

   Both are documented config options available today. This PR adds a middle ground that preserves first-turn + post-compaction injection.

3. Compaction safety — compact.ts always re-injects full bootstrap context independently (line 729), so workspace files are restored after compaction events.

4. LLM API is stateless — the system prompt is rebuilt on every API call. On continuation turns with continuation-skip, the model does not see bootstrap files in its system prompt. However, the previous turns (including the first turn with full bootstrap) remain in the conversation history, so the model still has access to the behavioral context from the initial injection.

The tradeoff (token savings vs. reduced system prompt surface on continuation turns) is intentional and opt-in. The existing skipBootstrap flag is strictly more aggressive than this feature.

Addressed Greptile's style nits in 769d5a0.

This is a useful optimization target, but I do not think it is merge-ready as written.

Two behavioral regressions stand out:

• continuation is detected from sessionFile existence, not from real prior-turn state. Header-only / pre-created session files can exist before the first successful assistant turn, so this can skip bootstrap on a recovered first turn.
• heartbeat continuation under lightweight context loses HEARTBEAT.md, because this bypasses resolveBootstrapContextForRun(...) entirely instead of preserving the existing heartbeat-only filtering path.

I would want the continuation-skip gate tightened to real transcript state with at least one assistant turn, heartbeat lightweight semantics preserved, and run-level tests added for:

• header-only or pre-created session file
• heartbeat continuation
• post-compaction reinjection

Also worth being explicit in the PR description: this can help workspace-bootstrap overhead, but it does not address the broader token-burn complaints from Mission Control heartbeats, repeated skill prompt injection, or long-session history growth.

I think the underlying issue in #9157 is real and clear, but this specific fix is still using the wrong signal.

The new guard in src/agents/pi-embedded-runner/run/attempt.ts treats fs.stat(sessionFile) as equivalent to “bootstrap context is already represented in the model’s effective context”. In this runner, that is not a safe assumption.

Two concrete cases break:

1. Pre-created / repaired / empty sessions

prepareSessionManagerForRun() explicitly handles hadSessionFile && header && !hasAssistant as a first-run state and resets the file so the first assistant flush persists header + user + assistant in order:

• src/agents/pi-embedded-runner/session-manager-init.ts

So an existing session file does not necessarily mean the session has already had a real assistant turn with bootstrap context available. With contextInjection: continuation-skip, those sessions now skip AGENTS/SOUL/bootstrap injection too early.

2. Post-compaction retry

The PR description says compaction is safe because compact.ts resolves bootstrap context independently. That is only true for the compaction prompt itself.

After successful compaction, the main run loop retries by calling runEmbeddedAttempt() again:

• src/agents/pi-embedded-runner/run.ts (runEmbeddedAttempt(...))
• timeout recovery branch: if (timeoutCompactResult.compacted) { ... continue; }
• overflow recovery branch: if (compactResult.compacted) { ... continue; }

That retried attempt rebuilds the system prompt from scratch, but sessionFile still exists, so this new guard suppresses bootstrap injection on exactly the first post-compaction retry turn. compact.ts resolving contextFiles for the compaction operation does not persist that bootstrap context into later normal attempts.

So I don’t think session file exists is the right discriminator here. The fix needs a signal closer to “this session already has a completed prior assistant turn / safe-to-skip bootstrap”, or an explicit persisted marker/fingerprint that can be invalidated after compaction.

I’d want regression coverage for at least:

• pre-created session file with no assistant turn yet
• repaired/empty session file
• first normal retry after successful compaction

Pushed bad2a92 addressing all review feedback. Here's what changed:

@steipete's feedback (both comments)

1. "continuation detected from sessionFile existence, not real prior-turn state"

Fixed. Replaced fs.stat(sessionFile) with hasCompletedBootstrapTurn(sessionFile) which reads the session JSONL and checks for at least one completed assistant turn (type: "message" with role: "assistant"). Pre-created, repaired, or header-only session files now correctly return false, ensuring bootstrap is always injected on the true first turn.

2. "heartbeat continuation under lightweight context loses HEARTBEAT.md"

Fixed. The continuation-skip gate now explicitly excludes heartbeat runs (params.bootstrapContextRunKind !== "heartbeat"), preserving the applyContextModeFilter path that keeps HEARTBEAT.md in lightweight heartbeat mode.

3. "post-compaction retry"

Fixed. hasCompletedBootstrapTurn tracks whether a type: "compaction" entry appears after the last assistant message. If so, it returns false, forcing bootstrap re-injection on the post-compaction retry. Once the retry completes (new assistant message after compaction), subsequent turns can safely skip again.

4. Regression tests requested

Added 8 tests for hasCompletedBootstrapTurn covering all requested scenarios:

• Pre-created session file with no assistant turn → false
• Empty session file → false
• Header-only session → false
• User-only messages → false
• Completed assistant turn → true
• Post-compaction retry (compaction after last assistant) → false
• Normal continuation after compaction + new assistant → true
• Malformed JSON lines → handled gracefully

Greptile style nits

Both addressed in previous commit (769d5a0, preserved through rebase):

• contextInjection field now uses AgentContextInjection type alias
• Blank line added between resolveContextInjectionMode and BootstrapContextRunKind

Codex inline comments

P1 "Detect continuation from transcript, not file existence" — same fix as steipete point 1 above.
P2 "Preserve HEARTBEAT.md injection" — same fix as steipete point 2 above.

Aisle Security concern

Addressed in previous comment — the feature is opt-in, has pre-existing precedent (skipBootstrap, lightweight mode), and compaction always re-injects. The new transcript-based detection adds further safety by ensuring bootstrap was actually injected and processed before skipping.

Re: updated Aisle analysis (2 issues):

1. Unbounded transcript read (CWE-400) — Acknowledged. Same concern as Codex P2 (streaming). The current implementation uses fast-path string checks before JSON parsing to minimize overhead. A streaming reader is a valid follow-up optimization for very large sessions but not a blocking concern for an opt-in feature that only runs when continuation-skip is explicitly configured.

2. Bootstrap context dropping — Same concern from the first Aisle analysis, already addressed in my earlier comment. Opt-in, pre-existing precedent (skipBootstrap, lightweight mode), compaction-safe.

No code changes needed — both are acknowledged limitations documented in the PR and tracked for follow-up.

closing this one out.

this was a real perf direction, but it has already landed differently on main: the current tree already has contextInjection / continuation-skip handling in the agent runtime and config schema. keeping this PR open now is just duplicate surface.

if there is still a gap after that landed version, the right move is a focused follow-up against current main rather than reviving this older branch.