tencent cloud

Tencent WorkBuddy Enterprise

DocumentationTencent WorkBuddy EnterpriseCodeBuddyCodeBuddy CodePreferenceMemory

Memory

Download
Focus Mode
Font Size
Last updated: 2026-09-30 18:15:49
AI-Translated
CodeBuddy Code can remember your preferences across sessions, such as code style guides and frequently used commands in your workflows.

Determining Memory Types

CodeBuddy Code provides four hierarchical memory locations, each with a different purpose:
Memory Type
Position
Purpose
Example Usage Scenario
Sharing Scope
User Memory
~/.codebuddy/CODEBUDDY.md
Personal preferences applicable to all projects
Code style preferences and personal tool shortcuts
Personal only (all projects)
User Rules
~/.codebuddy/rules/*.md
Modular personal rules
Personal coding habits and common workflows
Personal only (all projects)
Project Memory
./CODEBUDDY.md or ./.codebuddy/CODEBUDDY.md
Team-shared instructions for the project
Project architecture, coding standards, and common workflows
Shared with team members through source code management
Project Rules
./.codebuddy/rules/*.md
Modular project instructions organized by topic
Language-specific guidelines, testing specifications, and API standards
Shared with team members through source code management
Project Memory (Local)
./CODEBUDDY.local.md
Personal project-specific preferences
Your sandbox URL and preferred test data
Personal only (current project)
All memory files are automatically loaded into the context when CodeBuddy Code starts. The loading order is as follows:
1. User-level: Loads main files such as ~/.codebuddy/CODEBUDDY.md and all rules under ~/.codebuddy/rules/.
2. Project-level main files: All CODEBUDDY.md and CODEBUDDY.local.md files are recursively loaded upward from the current working directory.
3. Project-level rules: Loads only the rules under .codebuddy/rules/ in the current working directory (rules in parent directories are not loaded).
4. Subdirectory memory: When CodeBuddy operates on files in a subdirectory, the CODEBUDDY.md file in that subdirectory is dynamically loaded.
5. Local memory: Loads ./CODEBUDDY.local.md.
Note:
The CODEBUDDY.local.md file is automatically added to .gitignore, making it ideal for storing private project-specific preferences that should not be committed to version control.

CODEBUDDY.md Import

Other files can be imported into the CODEBUDDY.md file using the @path/to/import syntax. The following example imports 3 files:
Check @README for a project overview and @package.json for available npm commands.

# Additional Notes
- Git workflow @docs/git-instructions.md
Both relative and absolute paths are supported. In particular, importing files from a user's home directory is a convenient way for team members to provide personal instructions that are not committed to the repository. Imports serve as an alternative to CODEBUDDY.local.md and work better across multiple git worktrees.
# Personal Preferences
- @~/.codebuddy/my-project-instructions.md
To avoid potential conflicts, imports within code blocks and code spans are not parsed.
This code span is not treated as an import: `@tencent-ai/codebuddy-code`
Imported files can recursively import other files, up to a maximum depth of 5 levels. You can run the /memory command to view the loaded memory files.

How CodeBuddy Finds Memories

CodeBuddy Code reads memory recursively: starting from the current working directory, CodeBuddy Code recurses upward to the root directory (but not including the root directory /) and reads any CODEBUDDY.md or CODEBUDDY.local.md files it finds. This is especially convenient in large repositories when you run CodeBuddy Code in the foo/bar/ directory and have memory in both foo/CODEBUDDY.md and foo/bar/CODEBUDDY.md.
CodeBuddy also discovers CODEBUDDY.md files nested in subtrees under the current working directory. These files are not loaded at startup. They are included only when CodeBuddy reads files within those subtrees.

Managing Memories with /memory

Use the /memory slash command in a session to open the memory management panel. In this panel, you can:
Open the Auto Memory directory.
Open the MEMORY.md index file.
Toggle the Auto Memory switch.

Setting Project Memory

Suppose you want to set up a CODEBUDDY.md file to store important project information, conventions, and common commands. Project memory can be stored in ./CODEBUDDY.md or ./.codebuddy/CODEBUDDY.md.
Use the following command to bootstrap a CODEBUDDY.md for your codebase:
> /init
Tip:
Include common commands (build, test, lint) to avoid repeated searches.
Record code style preferences and naming conventions.
Add important project-specific architectural patterns.
CODEBUDDY.md memory can be used for both team-shared instructions and personal preferences.

Implementing Modular Rules with .codebuddy/rules/

For larger projects, you can use the .codebuddy/rules/ directory to organize instructions into multiple files. This allows teams to maintain focused, well-organized rule files instead of a single large CODEBUDDY.md.

Basic Structure

Place the markdown file in the project's .codebuddy/rules/ directory:
your-project/
├── .codebuddy/
│   ├── CODEBUDDY.md           # Main project instructions
│   └── rules/
│       ├── code-style.md      # Code style guide
│       ├── testing.md         # Testing standards
│       └── security.md        # Security requirements
All .md files in .codebuddy/rules/ are automatically loaded as project memory with the same priority as .codebuddy/CODEBUDDY.md.
Note:
Project-level rules are loaded only from .codebuddy/rules/ in the current working directory (workDir), and rules in parent directories are not loaded. This ensures that the scope of rules is clear and unambiguous.

Rule Control Fields

Rule files support the following YAML frontmatter fields to control loading and application behavior:
Field
Type
Default Value
Description
enabled
boolean
true
Whether to load this rule. When set to false, the rule is not loaded at all.
alwaysApply
boolean
true
Whether to always apply this rule
paths
string/string[]
-
glob pattern of file paths that trigger the rule

Rule Type Determination

The rule type is determined by both alwaysApply and paths:
alwaysApply
paths
Rule Type
Behavior
true (default)
Any
ALWAYS
Always inject into the context.
false
Has a value
MANUAL (conditional trigger)
Triggers only when an operation matches a file.
false
None
Not supported
The rule is not loaded.

Example

Always-applied rules (default behavior):
---
# alwaysApply defaults to true and can be omitted.
---

# General code standards

- Use 2-space indentation
- Keep a blank line at the end of the file.
Conditional rules:
---
alwaysApply: false
paths: src/api/**/*.ts
---

# API Development Rules

- All API endpoints must include input validation.
- Use the standard error response format.
- Include OpenAPI documentation comments.
Disable rules (temporarily):
---
enabled: false
---

# Rules not currently in use
Note:
The paths field is not limited to the .codebuddy/rules/ directory. It can be used in all memory files, including CODEBUDDY.md and CODEBUDDY.local.md.

Glob Pattern

The paths field supports standard glob patterns and has the matchBase option enabled:
Mode
Match
**/*.ts
All TypeScript files in any directory
*.ts
All TypeScript files in any directory (matchBase mode)
src/**/*
All files in the src/ directory
*.md
Markdown files in any directory
src/components/*.tsx
React components in a specific directory
About matchBase: When matchBase is enabled, patterns that do not contain path separators (such as *.ts) match files in any directory. For example, *.ts can match src/utils/helper.ts.
You can use braces to efficiently match multiple patterns:
---
paths: src/**/*.{ts,tsx}
---

# TypeScript/React Rules
This expands to match src/**/*.ts and src/**/*.tsx. You can also combine multiple patterns with commas:
---
paths: {src,lib}/**/*.ts, tests/**/*.test.ts
---

Subdirectory

Rules can be organized into subdirectories for better structure:
.codebuddy/rules/
├── frontend/
│   ├── react.md
│   └── styles.md
├── backend/
│   ├── api.md
│   └── database.md
└── general.md
All .md files are discovered recursively.

Symbolic Link

The .codebuddy/rules/ directory supports symbolic links, allowing you to share common rules across multiple projects:
# Sharing Rule Directories via Symbolic Links
ln -s ~/shared-codebuddy-rules .codebuddy/rules/shared

# Symbolically Linking a Single Rule File
ln -s ~/company-standards/security.md .codebuddy/rules/security.md
Symbolic links are resolved and their content is loaded normally. Circular symbolic links are detected and handled gracefully.

User-Level Rules

You can create personal rules that apply to all projects in ~/.codebuddy/rules/:
~/.codebuddy/rules/
├── preferences.md    # Your personal coding preferences
└── workflows.md      # Your preferred workflows
User-level rules are loaded before project rules, giving project rules higher priority.
Usage Recommendations:
Keep Rules Focused: Each file should cover a single topic (such as testing.md or api-design.md).
Use descriptive filenames: The filename should indicate what the rule covers.
Use Conditional Rules Sparingly: Add paths frontmatter only when a rule genuinely applies to specific file types.
Organize with subdirectories: Group related rules (such as frontend/ or backend/).

Memory Usage Recommendations

Be specific: "Use 2-space indentation" is better than "Format code properly."
Use structure: Format each memory as a bullet point, and group related memories under descriptive markdown headings.
Review regularly: Update memories as the project evolves to ensure CodeBuddy always uses the latest information and context.

Setting Language Preferences

It is recommended to use the /config command to configure the preferred response language (see Settings Configuration for details), which is the simplest and most direct method:
> /config
# Select Language and enter your preferred language, such as "Simplified Chinese".
If you need finer-grained control (such as the language for code comments or commit messages), you can add the following to your memory file:
## CodeBuddy Added Memories

### Language Preferences
- Write code comments in Chinese.
- Write commit messages in Chinese.
Project-level language settings override user-level settings.

Layered Memory Policy Example

User-Level Memory (~/.codebuddy/CODEBUDDY.md)

## CodeBuddy Added Memories

### Tool Preferences
- Use pnpm instead of npm

### Code Preferences
- Prefer a functional programming style
- Prioritize code readability.
Tip:
It is recommended to set the response language through /config rather than configuring it in the memory file.

Project-Level Memory (./CODEBUDDY.md)

## CodeBuddy Added Memories

### Project Architecture
- Use a microservices architecture.
- Frontend: React + TypeScript
- Backend: Node.js + Express

### Team Conventions
- A PR requires review by two people.
- Follow Conventional Commits.

Local Project Memory (./CODEBUDDY.local.md)

## CodeBuddy Added Memories

### Local Development Configuration
- Database port: 5433
- Use debug mode.
- Skip CI quick tests.

Auto Memory System

Auto Memory is the automatic memory system of CodeBuddy Code, allowing CodeBuddy to automatically save and retrieve persistent memories across sessions. Unlike the static memory in CODEBUDDY.md, Auto Memory is autonomously determined by CodeBuddy during its work regarding what content to save.

Storage Location

Project memory: ~/.codebuddy/memories/{project-id}/
Global memory: ~/.codebuddy/memories/global/
Each project has a MEMORY.md index file, and its first 200 lines are automatically loaded into the session context. Detailed memory content should be stored in separate topic files (such as preferences.md and decisions.md) and linked from MEMORY.md.

Enabling and Disabling

Toggle the Auto Memory switch in the /config panel.
Switch through the /memory command panel.
Configure in settings.json: "memory": { "autoMemoryEnabled": false }
Through the environment variable: CODEBUDDY_DISABLE_AUTO_MEMORY=1

Typed Memory Mode

Typed Memory is an enhanced version of Auto Memory that provides a structured memory type system (enabled by default). Memory files are managed using YAML frontmatter and four types.
Four memory types:
Type
Purpose
Example
user
User roles, goals, preferences, and knowledge background
The user is a senior backend engineer and is proficient in Go.
feedback
User corrections and guidance for CodeBuddy behavior
Do not mock the database in tests.
project
Work, goals, and decisions in ongoing projects
Freeze non-critical merges starting next Wednesday.
reference
References to external systems and resources
bug tracking is in the Linear project INGEST.
Memory file format:
---
name: User role
description: The user's professional background and technical expertise
type: user
---

The user is a senior backend engineer with 10 years of Go experience, but is new to the React frontend of the project.
Disable method (if you need to fall back to the generic format):
Configure in settings.json: "memory": { "typedMemory": false }
Through the environment variable: CODEBUDDY_TYPED_MEMORY_ENABLED=false
Tip:
Typed Memory is enabled by default. If Typed Memory is disabled, Auto Memory uses a simplified generic format without a type system or YAML frontmatter.

Caching and Reloading

Operation
Reload
Description
Process Restart
Yes
Cache Cleared
Edit via /memory
Yes
Automatically Clear Cache
/clear Command
No
Clear Message History Only
Manually Modify Files
No
Manual Restart Required
Add/Delete Rule Files
No
Manual Restart Required

FAQs

What is the difference between AGENTS.md and CODEBUDDY.md?
CodeBuddy Code supports both AGENTS.md and CODEBUDDY.md as project memory files:
AGENTS.md support: If a CODEBUDDY.md file exists in the project, project-level memory uses CODEBUDDY.md. Otherwise, AGENTS.md is used.
Automatic detection: The system automatically detects whether an AGENTS.md file exists in the project.

Recommended Use of CODEBUDDY.md

Although we maintain support for AGENTS.md, we recommend that new projects use CODEBUDDY.md as the memory file name to maintain consistency with the CodeBuddy Code brand.
How do I migrate AGENTS.md to CODEBUDDY.md?
Rename AGENTS.md to CODEBUDDY.md. The system detects it automatically, and CODEBUDDY.md is loaded with priority.
How are memory files synchronized?
Project memory: Sync with your team through Git.
User memory: Stored locally and not synchronized.
Local project memory: Stored locally and automatically added to .gitignore.
When are conditional rules triggered?
Triggered in the following cases:
When a file is referenced with @path/to/file
When using file operation tools such as Read, Glob, Grep, Edit, and Write
After triggering, the matching rules are injected into the current message context as system reminders. Once all conditional rules have been injected, they are not injected again.
How do I debug rule loading issues?
1. Run /memory to view the list of loaded rules.
2. Check whether the frontmatter format is correct (--- delimiter).
3. Check whether the glob pattern matches.
4. Restart CodeBuddy to clear the cache.
Is there a limit on the rule file size?
Keep it concise. For very large specification documents, use the @import syntax to reference them instead of including them directly.

Compatibility with CodeBuddy IDE

Both CodeBuddy Code CLI and CodeBuddy IDE support the memory/rules feature, but conditional rules are triggered differently:
CLI: Conditional rules are triggered by automatically matching file operations through glob patterns (including @ references and tool calls), and do not support intelligent rule selection by the model.
IDE: Conditional rules support manual referencing by users through @RuleName, and also support context-based intelligent decision-making by the model to activate rules.
Previous Topic: Model ConfigurationNext Topic: Status Line Configuration

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback

Search
    Enter keywords to search documentation