Busabase × JunieKnowledge Base for Junie
Junie can run in JetBrains IDEs, an interactive CLI, headless CI, GitHub Actions, and GitLab pipelines. Project trust, guidelines, Skills, MCP, approval modes, sandbox policy, and review agents shape each run differently. Durable knowledge starts by naming that execution surface.
Execution surfaces
IDE, CLI, and CI runs do not inherit one identical trust and approval model.
Junie works inside JetBrains IDEs, in an interactive terminal, and headlessly in pipelines. Record the surface, authentication, repository checkout, model/provider, and whether a human could intervene.
| Surface | Human interaction | Primary evidence |
|---|---|---|
| JetBrains IDE | Interactive | IDE actions, inspections, diff |
| Junie CLI | Interactive or headless | Session events, commands, files |
| GitHub Action | Pipeline-triggered | PR, checks, action logs |
| GitLab CI/CD | Issue/MR-triggered | Pipeline, MR, artifacts |
Project trust
A repository can be writable while its Junie configuration remains deliberately untrusted.
Interactive CLI asks before loading project config, MCP, hooks, agents, commands, Skills, guidelines, and project memory. An untrusted project uses temporary Junie storage. Non-interactive and ACP launches are trusted by design because they cannot prompt, so pipeline governance must be explicit.
Symlinks and scope resolved
Exact project or parent scope
Only trusted project sources
Surface-specific controls apply
Owner accepts shared state
Guidelines and memory
AGENTS.md supplies persistent guidance; memory remains context that must be curated.
Junie resolves `.junie/AGENTS.md`, root AGENTS.md plus playbook/rules, and legacy guidelines in a defined order, then combines project and global guidance. Keep instructions concise and versioned. Move changing decisions into reviewed records instead of teaching them as permanent behavior.
Repository conventions and commands
Personal or organization-wide preferences
Context extracted for later sessions
Accepted state with owner and freshness
Agent Skills
Portable Skills encode focused procedures and support files, not current approval state.
Junie loads Skills from project, user, `.agents`, extension, and custom locations. They may run automatically or via slash command and can execute bundled scripts. Review third-party Skill content and pin its revision before using its output as evidence.
Procedure, templates, scripts, domain checklist
Accepted outcome, responsible owner, lifecycle
Approval stack
Action Allowlist, Brave mode, and sandbox reduce friction and blast radius in different ways.
Allowlist entries skip prompts for selected action types. Brave mode controls how often Junie asks. Sandbox wraps terminal commands only and does not cover file edits, MCP servers, hooks, or Junie-managed Git operations. None of these controls approve a business claim.
| Control | What it changes | What it does not prove |
|---|---|---|
| Action Allowlist | Future prompts for matched actions | That the result is correct |
| Brave mode | Ask / auto / broad execution behavior | That credentials are appropriate |
| Sandbox | Terminal filesystem/network blast radius | That all Junie actions are isolated |
| Change Request | Acceptance into shared records | That execution can be repeated |
MCP scopes
Project and user MCP configs have different sharing and secret risks.
Junie uses `.junie/mcp/mcp.json` for project scope and `~/.junie/mcp/mcp.json` for user scope, supports local and remote servers plus OAuth, and reports runtime status. ACP clients can list supplied and local servers but do not edit configs through the installation assistant.
Shareable config; never commit secrets
Private machine-wide configuration
Client-supplied and local runtime list
Evidence-backed state after execution
Review evidence
Junie's code review agent is read-only analysis; accepting a suggestion is still a separate action.
The review agent reads diffs and project context without editing files, running builds/tests, committing, or pushing. Preserve the review target, finding, acceptance or dismissal, subsequent patch, tests, and final repository revision.
Knowledge contract
Connect the repository outcome to the Junie surface and control state that produced it.
The record remains compact while keeping enough provenance to reproduce or challenge the result.
outcome_keyStable identityexecution_surfaceIDE, CLI, GitHub, or GitLabsession_or_runSession, pipeline, or action referencetrust_configProject trust and config digestguidance_refsAGENTS.md, Skills, and memory usedaction_evidenceCommands, MCP calls, diffs, logsverificationReview findings, tests, readbackowner_decisionAccountable acceptance and freshnessPractical questions
Junie knowledge base FAQ
Does Busabase replace Junie guidelines?
No. Guidelines shape Junie behavior. Busabase stores selected reviewed outcomes.
Is an untrusted project unreadable to Junie?
No. Current docs say ordinary workspace file operations remain available while project-provided Junie configuration is not loaded.
Does sandbox cover MCP and file edits?
No. Current Junie docs limit sandbox wrapping to terminal commands.
Does an Action Allowlist entry approve an MCP result?
No. It can remove a confirmation prompt; the result still needs evidence and review.
Can code review findings become records directly?
Keep the finding as evidence, then record the accepted patch, verification, owner, and final revision.
Start with one verified Junie run
Name the surface, trust decision, controls, and final repository evidence.
Choose one IDE, CLI, or CI task that reached a stable outcome. Preserve its execution boundary and submit only the reusable result for review.