The Activity log

The Activity Logs takeover (reached from the footer) captures every backend call the app makes — git2 operations and shell-outs alike — as a flat, filterable stream. Capture is always on; there is no separate opt-in. It's the debugging counterpart to the Action Journal (AI features section): the journal reframes the same underlying log for a reader who wants to learn what an action did, this view is the raw trace for whoever is chasing why something broke.

Filtering the activity log to errors only

Every call is captured whether it succeeds or fails, so switching the level filter to Errors narrows a long stream down to just the operations that actually went wrong.

Captured from the running app by this scenario.

Do this

1. Click the toolbar fetch button
2. Open the activity logs
3. Filter the activity log to errors only
4. Open the fetch_remote activity log entry

You should see

• The activity log does not show a get_repo_status entry
• The activity log detail shows the error for fetch_remote

Narrowing the activity log to the active repository

"Application" is the default: every operation the app has run, across every repository you've touched. Switching to "Repository" narrows the same stream down to just the one that's currently open — useful once the Application view has piled up work from repositories you aren't looking at anymore.

Captured from the running app by this scenario.

Do this

1. Click the toolbar fetch button
2. Open the activity logs
3. Switch the activity log scope to repository

You should see

• The activity log scope is application
• The activity log shows a fetch_remote entry
• The activity log scope is repository
• The activity log shows a fetch_remote entry

Tracing a multi-step action narrows the log to just its own operations

Creating and checking out a branch is one user gesture but two backend calls sharing a correlation id — the trace chip narrows the stream down to just those, hiding everything else the app did around it.

Captured from the running app by this scenario.

Do this

1. Select the HEAD~1 commit in the graph
2. Open the command palette
3. Run the command palette action commit-branch
4. Enter the branch name feature/traced
5. Confirm the branch creation
6. Open the activity logs
7. Open the checkout_branch activity log entry
8. Trace the activity log entry
9. Clear the activity log trace

You should see

• The create branch dialog is shown
• The branch feature/traced exists
• The activity trace chip is shown
• The activity log shows a create_branch entry
• The activity log shows a checkout_branch entry
• The activity log does not show a get_repo_status entry
• The activity trace chip is not shown
• The activity log shows a get_repo_status entry

---

This page is generated from apps/e2e/features/activity-log.feature, the end-to-end test that drives the feature it describes.