Debugging with log

blamely log tails tool-specific log files in real time and shows you exactly what the daemon’s watchers detect. Use it when attribution looks wrong and you want to see what signals are arriving.

blamely log cursor #

blamely log cursor

Watches Cursor’s extension-host log files and prints every line the CursorLogWatcher would record as a Composer or Agent apply event.

Sample output when a Composer session applies a change:

Scanning Cursor logs in ~/Library/Application Support/Cursor/logs
Showing detected AI-apply events only (use --debug to see all lines).

[MATCH] 2024-01-15/exthost/output/composerService.log  →  /Users/you/project/src/auth.go
[MATCH] 2024-01-15/exthost/output/composerService.log  →  /Users/you/project/src/auth_test.go

Each [MATCH] line means the daemon recorded a tool=cursor, gen_type=chat edit event for that file. If you commit immediately after, those files’ lines are attributed to Cursor.

blamely log devin #

blamely log devin

Devin CLI attribution is hook-driven, so there is no log file to tail. Instead this prints every new tool=devin edit the moment the daemon records it. Trigger an edit in Devin CLI and watch for it. Nothing is written by this command; Ctrl+C stops it.

If nothing appears, check that ~/.config/devin/config.json has a PostToolUse hook running blamely record devin (blamely doctor checks it) and that the daemon is running. Devin Cloud commits never show up here — they’re attributed on git pull instead.

The --debug flag #

blamely log cursor --debug

Prints every scanned line, prefixed with its classification:

Use --debug when a Composer action isn’t being attributed: it shows the raw log lines so you can check whether the apply keyword is present and whether the file path was extracted correctly.

What gets detected (and what doesn’t) #

The log watcher matches lines that contain composerApply, composer.apply, agentEdit, agent.edit, or agent.apply. It deliberately does not match the generic applyEdit keyword — VS Code uses that for Tab completions, formatter rewrites, and LSP code actions too, which would cause over-attribution.

Cursor Tab completions are not logged here. They’re detected by the VS Code/Cursor editor plugin via the editor.action.inlineSuggest.commit command — the only accept-precise signal. See Cursor installation.

When is this useful? #

• Composer applied a change but the commit shows those lines as Human.
• You want to confirm the daemon is picking up Cursor activity before committing.
• You’re debugging a new project structure where file paths might not be resolving correctly.

Related #

• blamely status — daemon health and recent activity counts.
• blamely doctor — checks whether the Cursor hook is wired.
• ~/.blamely/daemon.log — the daemon’s own log (all watchers, all tools).

Next #

• Detection model — which tools are detected and how.
• Installation: Cursor — Tab completion setup.
• Troubleshooting — common fixes.