Workspace

Changes

Track and review all changes to your project workspace before committing.

Review and validate all file modifications made during the active session before committing or creating a pull request.

The Changes view shows every file that has been modified in the current session’s branch. This includes edits made by the agent, manual edits from connected editors, and changes triggered by terminal commands.

All changes are scoped to the session’s working branch and remain isolated until you explicitly merge or create a pull request.

What You See in Session Changes

The panel displays:

  • Total number of files changed
  • Lines added and removed
  • A list of modified files
  • Per-file change summaries
  • Local commits created within the session

When you select a file, a full diff view appears so you can inspect changes line by line.

Example:

If you ask the agent to create API integration tests, you might see:

  • chat-route.test.ts → +844 lines
  • playwright.config.ts → +7 lines
  • README.md → +236 lines

This tells you immediately that new test logic was added, configuration was updated, and documentation was expanded.

Reviewing Agent-Generated Changes

Use Session Changes to validate agent output before moving forward.

Use Case: Implementing Integration Tests

You instruct the agent:

“Create integration tests for the chat API.”

After completion:

  1. Open Session Changes
  2. Review the new chat-route.test.ts file
  3. Confirm that:
    • All endpoints are covered
    • Error cases are included
    • No unrelated files were modified

This prevents unintended changes from entering your codebase.

Use Case: Refactoring a Component

You request:

“Refactor the navigation component to improve readability.”

Session Changes might show:

  • Navigation.tsx → modified
  • styles.css → modified
  • utils/navigation.ts → modified

Review the diff to ensure:

  • Logic remains unchanged
  • Imports are updated correctly
  • No accidental deletions occurred

Tracking Manual Edits

If you open the project in VS Code via Open With and rename several files, those changes will appear in Session Changes.

Example

You manually:

  • Rename UserCard.tsxProfileCard.tsx
  • Update all imports

Session Changes will show:

  • File rename
  • Modified import lines across affected files

This ensures that even external editor work is visible within Origin’s workflow.

Changes from Terminal Commands

Commands executed in the Terminal that modify files also appear here.

Example: Running a Code Formatter

You run:

npm run format

Session Changes may show:

  • Multiple files modified
  • Minor whitespace or style changes

You can review these before committing to confirm only formatting updates were applied.

Example: Running a Code Generator

You execute:

pnpm exec prisma generate

Session Changes may show:

  • New generated files
  • Updated schema-related artifacts

This allows you to validate generated outputs before promoting them.

Local Commits

Session Changes also displays Local Commits created during the session.

These commits:

  • Exist on the session branch
  • Are not merged automatically
  • Can be grouped logically before PR creation

Use Case: Logical Checkpoints

Instead of one large commit, you can:

  1. Commit test scaffolding
  2. Commit core test logic
  3. Commit documentation updates

This creates a clean review history.

Debugging Through Changes

Session Changes is also useful when something breaks.

Use Case: Identifying a Regression

If tests start failing:

  1. Open Session Changes
  2. Review the most recent file modifications
  3. Identify which change introduced the issue

Because changes are scoped to the session branch, debugging remains isolated and safe.

Relationship to Branches

Each session operates on a branch derived from the main branch.

Session Changes reflects:

  • The diff between the session branch and its base
  • All modifications accumulated during that session

Switching sessions will show a completely different set of changes tied to that session’s branch.

This allows:

  • Parallel feature development
  • Isolated debugging sessions
  • Experimental implementations without affecting other work

Preparing for a Pull Request

Before creating a PR:

  1. Open Session Changes
  2. Verify only relevant files are included
  3. Remove or revert unintended edits
  4. Confirm commit structure

This ensures clean, reviewable changes.

Best Practices

  • Always review diffs before merging
  • Keep session scope focused to minimize unrelated file edits
  • Use separate sessions for unrelated features
  • Create meaningful local commits instead of large, monolithic ones

On this page