How to Use Side Chat in Trae: Context, Shortcuts, and Pro Workflows

Key Takeaways

• Trae Side Chat is designed for broader coding conversations, including repository understanding, multi-file debugging, implementation planning, code generation, and architecture analysis.
• Open Side Chat with Command + U on macOS or Ctrl + U on Windows.
• Use Trae's # context tools to attach the smallest useful amount of project information instead of sending unnecessary repository context.
• Useful context options include #Code, #File, #Folder, #Workspace, #Problems, #Web, #Rule, and #Past Chats.
• Use Inline Chat for targeted edits and Side Chat for investigation and broader reasoning.
• For complex bugs, ask Trae to identify the root cause before modifying code.
• Review all generated changes and verify them with tests, type checking, linting, or the project's normal validation workflow.

What Is Side Chat in Trae?

Side Chat is Trae's persistent AI conversation panel for development tasks that need more context and multi-step reasoning than a small inline edit.

It is useful when the AI needs to understand relationships between files, investigate an unknown bug, explain an unfamiliar repository, compare implementation approaches, or plan a feature before editing code.

Typical Side Chat tasks include:

• Understanding a repository architecture.
• Tracing authentication or authorization flows.
• Debugging errors involving several files.
• Reviewing API implementations.
• Planning database or schema changes.
• Analyzing terminal output.
• Working from IDE diagnostics.
• Comparing alternative implementations.
• Reviewing code before a refactor.

For example:

Trace the login flow from the API route through middleware and token validation. Identify where refresh tokens are created, stored, rotated, and invalidated.

This task spans multiple code paths, making Side Chat a better fit than a one-function inline edit.

How to Open Side Chat in Trae

The default Side Chat shortcut is:

• macOS: Command + U
• Windows: Ctrl + U

A reliable workflow is:

1. Open Side Chat.
2. Attach the relevant project context.
3. Describe the desired outcome.
4. State important constraints.
5. Ask Trae to analyze before editing when the task is complex.
6. Review any proposed code changes.
7. Run the appropriate verification commands.

Side Chat vs Inline Chat in Trae

Side Chat and Inline Chat solve different problems.

Use Side Chat for Broader Tasks

Side Chat is usually better when a request involves:

• Multiple files.
• Repository-wide questions.
• Unknown root causes.
• Architecture analysis.
• Implementation planning.
• IDE diagnostics.
• Terminal output.
• External documentation.
• Several rounds of discussion.

Example:

Review the authentication architecture in this repository. Explain how sessions are created and invalidated, identify duplicated authorization logic, and propose the smallest safe refactor.

Use Inline Chat for Local Changes

Inline Chat is faster when the exact code that needs changing is already known.

Example:

Refactor only the selected function to remove nested conditionals. Preserve its signature, return values, and error behavior.

A practical rule is:

If the exact edit target is already known, use Inline Chat. If Trae first needs to understand the problem or discover relevant code, start with Side Chat.

How to Use Side Chat Step by Step

1. Start With the Outcome

Avoid vague prompts such as:

Look at my project and fix it.

Use a concrete engineering goal instead:

Find why users are sometimes redirected to /login immediately after a successful OAuth callback. Trace session creation and validation first. Do not modify code until you identify the most likely root cause.

This defines the symptom, investigation area, and desired process.

2. Attach Only Relevant Context

More context is not always better.

Use the smallest context source that fully explains the task:

• #Code for a specific function or symbol.
• #File for a complete file.
• #Folder for a feature directory.
• #Workspace for repository-wide discovery.
• #Problems for IDE diagnostics.
• #Web for current external documentation.
• #Rule for project-specific development rules.
• #Past Chats for earlier decisions or discussions.

This reduces noise and gives Trae a clearer problem boundary.

3. State What Must Not Change

Production prompts should include explicit invariants.

Useful constraints include:

• Keep the public API unchanged.
• Do not add dependencies.
• Preserve database compatibility.
• Do not rename exported symbols.
• Do not modify generated files.
• Follow existing project conventions.
• Do not perform unrelated cleanup.

Example:

Fix duplicate webhook processing. Preserve the current endpoint and database schema. Do not add dependencies. Follow the idempotency pattern already used elsewhere in this repository.

4. Ask Trae to Analyze Before Editing

For difficult bugs or risky code, separate investigation from implementation.

Use:

Analyze the problem first. Identify the likely root cause and the files involved. Do not modify code until the evidence is clear.

This reduces the risk of Trae changing the first suspicious code block without confirming that it actually caused the issue.

5. Require Verification

Do not stop at code generation.

Add a verification requirement:

After making the change, add one regression test for the original failure and list the commands needed to verify type checking and the relevant test suite.

This makes the workflow more reliable and easier to review.

How to Use #Code in Side Chat

Use #Code when the task centers on a specific function, class, method, or symbol.

Example:

#Code Explain how this retry function handles cancellation and identify any path that could send a duplicate request.

This is useful when the selected code is known but the developer wants analysis before deciding whether to edit it.

How to Use #File

Use #File when imports, exports, helpers, and interactions within one complete file matter.

Example:

#File Review this authentication service for token lifecycle bugs. Focus on creation, expiration, refresh, and revocation.

A full-file context often works better than #Code when the problem involves several functions inside the same module.

How to Use #Folder

Use #Folder when a feature is concentrated inside a directory such as src/auth/, app/api/payments/, or features/billing/.

Example:

#Folder Analyze this billing module for duplicated payment logic. Identify shared behavior that could be centralized without changing the public API.

This can provide enough context without introducing the noise of a full repository search.

How to Use #Workspace

Use #Workspace when relevant code must be discovered across the repository.

Example:

#Workspace Find every location where User.role is checked and summarize whether authorization logic is centralized or duplicated.

#Workspace is especially useful for:

• Repository architecture questions.
• Cross-cutting security logic.
• Shared data models.
• API usage discovery.
• Large refactoring analysis.

However, it should not be the default for every question. Narrower context is usually easier for both the model and the developer to validate.

How to Use #Problems

Use #Problems when Trae should reason about diagnostics already detected by the IDE.

Example:

#Problems Group these TypeScript errors by likely root cause. Identify which errors are primary and which are downstream before changing code.

This is more useful than fixing errors one at a time when a single incorrect type or configuration can trigger dozens of secondary diagnostics.

How to Use #Web

Use #Web when the solution depends on current external documentation.

Typical use cases include:

• Framework migration guides.
• Recently changed APIs.
• New library versions.
• Deprecated parameters.
• Official configuration examples.

Example:

#Web Compare the current official API documentation with this implementation and identify deprecated parameters or changed defaults.

This is especially useful when the repository may have been written against an older library version.

How to Use #Rule

Use #Rule when the project contains development rules Trae should follow.

Examples of project rules include:

• Route handlers must not directly query the database.
• All external input must go through a validation layer.
• Certain dependencies are prohibited.
• Errors must use a standard result format.
• Tests must follow a specific naming convention.

Including project rules helps prevent generated code from introducing patterns that conflict with the rest of the codebase.

How to Use #Past Chats

Use #Past Chats when previous Trae conversations contain decisions or requirements relevant to the current task.

This can be useful when a project discussion already established:

• An architecture decision.
• A naming convention.
• A migration strategy.
• A security constraint.
• A rejected implementation approach.

Instead of restating everything, relevant prior conversation context can help maintain consistency.

Add Selected Code to Side Chat

A useful workflow is to select suspicious code in the editor and use that code as the starting context for Side Chat.

Example:

This function sometimes returns stale data after rapid navigation. Explain the likely race condition, then inspect related request-cancellation code before proposing a fix.

This combines local context with the broader reasoning capabilities of Side Chat.

It is especially useful when one function appears suspicious but the root cause may exist elsewhere.

Use Side Chat With Terminal Output

Terminal output is valuable context for build failures, runtime errors, package problems, and failed tests.

A strong debugging prompt is:

Analyze this terminal output. Identify the first meaningful failure rather than the final cascading error. Then locate the responsible source or configuration and propose the smallest fix.

This matters because the final line of a failing command is often only a consequence of an earlier error.

Use Side Chat With Screenshots

Side Chat can also be useful for visual debugging when image input is available.

Typical use cases include:

• Broken layouts.
• Design references.
• Error dialogs.
• Visual regressions.
• UI implementation comparisons.

Example:

Compare this screenshot with the current React implementation. Identify the three largest layout differences and update only the relevant component styles.

The prompt should clearly describe what the image is being used to evaluate rather than simply attaching a screenshot without instructions.

Use Side Chat to Understand an Unfamiliar Repository

Avoid asking:

Explain this repo.

Instead, investigate progressively.

Start with:

#Workspace Map the high-level architecture of this repository. Identify runtime entry points, major packages, persistence layers, external services, and the request flow for the primary application.

Then narrow the investigation:

Which files implement authentication, and how do requests move between them?

Then verify a specific concern:

Show where authorization is enforced. Distinguish authentication checks from permission checks.

Progressive questioning produces a more useful mental model than requesting an exhaustive explanation in a single prompt.

Use Side Chat for Multi-File Debugging

A strong debugging request separates evidence from assumptions.

Use this template:

Symptom:
[what happens]

Expected behavior:
[what should happen]

Reproduction:
[smallest reproducible sequence]

Context:
[attach code, files, logs, or Problems]

Task:
Trace the root cause before changing code. Explain the evidence for the most likely cause. Implement the smallest fix and add a regression test.

This makes it less likely that the AI will make speculative changes.

Use Side Chat for Implementation Planning

Side Chat is valuable before any code changes begin.

Example:

#Workspace Plan how to add organization-level API keys.

Requirements:
- Existing personal API keys must keep working.
- Organization owners can create and revoke organization keys.
- Keys must never be stored in plaintext.
- Existing rate limiting should apply per organization.

Before editing:
1. Identify affected files and data models.
2. Describe the migration.
3. List security risks.
4. Propose an implementation sequence.
5. Identify required tests.

Plan-first prompting is particularly useful for authentication, billing, permissions, database migrations, infrastructure, and API compatibility work.

Best Prompt Formula for Trae Side Chat

A strong Side Chat request usually contains six elements:

Goal + evidence + context + constraints + process + verification

A reusable template is:

Goal:
[desired outcome]

Current behavior:
[what happens now]

Expected behavior:
[what should happen]

Context:
[attached code, files, workspace, diagnostics, or documentation]

Constraints:
[what must remain unchanged]

Process:
[analyze first, then plan, then edit]

Verification:
[tests, type checks, linting, build, or manual checks]

This structure is much more reliable than trying to compress a complex engineering task into a single vague sentence.

Practical Side Chat Prompt Examples

Repository Analysis

#Workspace Explain this project for a new maintainer. Focus on runtime entry points, data flow, authentication, persistence, background jobs, and external APIs. Reference the relevant files for each part.

TypeScript Build Failure

#Problems Group these errors by likely root cause. Identify the primary failure, explain which errors are downstream, and propose the minimum edits needed to restore the build.

API Security Review

Review this endpoint and its related service code for input validation, authorization, error handling, idempotency, and accidental data exposure. Do not modify code yet. Return concrete findings tied to specific code paths.

Refactor Planning

#Folder Analyze this billing module for duplicated payment logic. Propose a refactor that centralizes shared behavior without changing the public API. Identify migration risk and required tests.

Debugging From Logs

Use the attached terminal output to identify the first meaningful failure. Trace it to the responsible code or configuration. Do not fix secondary errors until the root cause is addressed.

Ask Trae to List Files Before Editing

When the task may affect several files, require Trae to explain its intended scope before making changes.

Example:

Before editing, list every file you intend to change and explain why each file is necessary. Do not modify any additional files without first explaining the reason.

This is particularly useful for large codebases because it makes scope creep easier to identify.

Separate Bug Fixes From Refactoring

Combining a bug fix with an architectural cleanup can make verification much harder.

Use:

Fix only the reported bug. Do not perform unrelated refactoring, renaming, formatting changes, or architecture cleanup.

Once the bug is verified, a separate conversation can address refactoring.

This creates smaller diffs and makes regressions easier to diagnose.

Use Behavioral Examples

Concrete examples help Trae distinguish requirements from assumptions.

Instead of:

Fix date validation.

Use:

Fix the date validation. 2026-02-28 must be accepted, 2026-02-30 must be rejected, and empty input must continue returning null.

Specific examples provide testable acceptance criteria.

Common Side Chat Mistakes

Using #Workspace for Everything

More repository context can introduce irrelevant code.

A useful escalation order is:

#Code → #File → #Folder → #Workspace

Start narrow and expand only when necessary.

Asking for a Fix Before Finding the Root Cause

Avoid:

Fix this error.

Prefer:

Identify the root cause first. Explain the evidence connecting the failure to the responsible code. Then implement the smallest fix.

Mixing Several Goals Into One Prompt

Do not combine debugging, refactoring, dependency upgrades, performance optimization, and documentation cleanup unless those tasks genuinely depend on each other.

Split them into separate steps.

Omitting Expected Behavior

Always provide:

• What happened.
• What should have happened.
• How to reproduce it.

Without expected behavior, the AI may optimize for the wrong outcome.

Accepting AI Explanations as Verification

A convincing explanation is not proof that the implementation works.

Run real project checks such as:

npm run typecheck

npm test

npm run lint

Troubleshooting Trae Side Chat

Command + U or Ctrl + U Does Not Work

Check whether:

• The editor currently has focus.
• The keybinding has been customized.
• Another extension is using the same shortcut.
• The operating system intercepts the key combination.

Review Trae's keyboard shortcut settings if necessary.

Side Chat Cannot Find Relevant Code

Possible causes include:

• The wrong project is open.
• Repository indexing is incomplete.
• The relevant file is excluded.
• The request is too broad.
• The selected context type is not appropriate.

Try attaching the exact file or folder before escalating to #Workspace.

Repository Answers Are Too Broad

Narrow the request.

Instead of:

#Workspace Explain authentication.

Use:

#Workspace Find implementations of refresh-token rotation specifically. Ignore access-token validation unless it directly calls the refresh flow.

Trae Wants to Change Too Many Files

Require an edit plan:

List the minimum files required for this fix before editing. Do not modify unrelated files.

The Conversation Becomes Too Long

Summarize the current state before continuing.

A useful prompt is:

Summarize the confirmed root cause, decisions made, files involved, remaining work, and constraints. Exclude discarded hypotheses.

This helps reduce confusion when a debugging session becomes lengthy.

Side Chat and Sensitive Code

Treat AI chat context as part of the project's security model.

Avoid unnecessarily including:

• Production API keys.
• Passwords.
• Session tokens.
• Private certificates.
• Customer personal data.
• Database dumps containing sensitive information.

Use sanitized logs and minimal code context whenever possible.

Organizations should also review Trae's current privacy settings and internal security requirements before using AI tools with proprietary repositories.

Side Chat vs Agent Workflows

Side Chat is particularly useful for understanding and reasoning.

Use Side Chat when the primary goal is to:

• Understand.
• Investigate.
• Compare.
• Diagnose.
• Plan.

Use a more agentic workflow when the primary goal is to:

• Search many files.
• Modify multiple modules.
• Run commands.
• Create files.
• Run tests.
• Iterate through failures.
• Complete a larger implementation sequence.

A strong workflow is often:

1. Use Side Chat to define the problem.
2. Confirm the root cause or implementation plan.
3. Define constraints.
4. Hand the bounded implementation to an agentic workflow.
5. Verify the resulting diff and tests.

FAQ

What is the shortcut for Side Chat in Trae?

Use Command + U on macOS or Ctrl + U on Windows.

What is the difference between Side Chat and Inline Chat?

Side Chat is designed for broader reasoning, repository exploration, debugging, planning, and multi-file context. Inline Chat is better for focused work around the current cursor position or selected code.

Can Side Chat analyze an entire repository?

Yes, repository-level context can be used when necessary, but narrower context such as a specific file or folder usually produces more focused results.

Should every Side Chat request use #Workspace?

No. Use the smallest context that contains enough information. #Code, #File, or #Folder is often preferable.

Can Side Chat help debug terminal errors?

Yes. Terminal logs can provide valuable evidence for build failures, runtime exceptions, package-manager problems, and failed tests.

Can Side Chat be used before editing code?

Yes. This is one of its strongest use cases. Ask Trae to investigate the problem, identify affected files, explain the root cause, and propose a plan before making changes.

Should Side Chat changes be accepted immediately?

No. Review the code diff and run relevant tests, linting, type checking, or build commands before committing meaningful changes.

Conclusion

Trae Side Chat is most effective as a context-controlled engineering workspace, not simply a generic AI chat box.

Open it with Command + U on macOS or Ctrl + U on Windows. Define the desired outcome, attach the smallest useful context, explain the expected behavior, and state what must remain unchanged.

For difficult tasks, separate understanding from editing. Ask Trae to identify the root cause, map relevant code paths, and propose a plan before modifying files. Then verify the result using tests, type checks, linting, build commands, and Git diff.

A practical starting point is to open Side Chat in an active project, attach one relevant file or code block, and ask Trae to explain the problem before requesting a fix. Once a task expands beyond one function or requires repository-wide reasoning, Side Chat becomes substantially more useful than treating every AI interaction as an inline edit.