Add Claude Code transcript logging as pr comment#1072
Conversation
Adds scripts/claude_logs/ with extract_transcript.py for extracting Claude Code session transcripts, and a CI check that blocks merging if log outputs haven't been cleaned up. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Is there way to get these logs directly in the github PR (either in the description or as a comment)? This would be more practical then merging them to the branch and adding a test to require they get deleted before the branch gets merged to main. |
Replace file-based output (JSONL + Markdown) with direct PR comment posting via the gh CLI. Each session gets its own collapsible comment identified by session ID, and re-running updates the existing comment in place. Remove the logs directory, .gitkeep, and the no-claude-logs GitHub workflow since committed log files are no longer needed. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude Code transcript log — 2026-04-21T1837-681a112e
No questions — the plan is clear. Let me start by reading the script from that branch. 1 tool call: Bash
Now let me create the new branch and set everything up. 3 tool calls: Bash, Bash, Bash
Now let me create all the files. I need to:
4 tool calls: Write, Bash, Write, Write
Here's what I've created on the
Want me to commit and push this as a PR?
Good point — the 2 tool calls: Write, Bash
Also need to update the GitHub Action check — it should now look for files other than 1 tool call: Edit
Done. Now logs can be committed for PR review visibility, the GitHub Action will block merging until they're cleaned up, and
11 tool calls: Bash, Bash, Bash, Glob, Glob, Read, Bash, Edit, Bash, Bash, Bash
PR created: #1072
6 tool calls: Bash, Bash, Bash, Bash, Bash, Bash
Done — transcript committed and pushed to the PR. The CI check on #1072 should now flag the logs, which is the expected behavior during review. You'll delete them before merging. |
Claude Code transcript log — 2026-04-21T1955-f2c5207c
Let me first check the current PR and understand what's needed. 5 tool calls: Bash, Glob, Bash, Glob, Bash
No comments on the PR yet. Let me look for the "previously generated markdown log" you mentioned. Let me search for any log files or recent outputs. 4 tool calls: Bash, Glob, Read, Read
I don't see an obvious "previously generated markdown log" in the repo. Could you point me to which file contains the log you want posted as a PR comment? The candidates I found are:
Which one are you referring to, or is it in a different location?
2 tool calls: Bash, Bash
6 tool calls: Bash, Bash, Bash, Glob, Read, Read
That's the end of the file — it looks like the transcript was cut off. Now let me post it as a collapsible PR comment. 1 tool call: Bash
Done. The transcript log has been posted as a collapsible comment on PR #1072: #1072 (comment) By default the log is hidden behind a
2 tool calls: Bash, Bash
Posted: #1072 (comment) Used Python this time to build the file so the content is properly embedded instead of relying on shell
Yes — gh api repos/ai2cm/ace/issues/comments/4291400981 --method PATCH --field body="updated content"So the workflow would be: regenerate the markdown log, rebuild the comment body, and PATCH the existing comment in place. No need to post a new one each time. Want me to try it out?
Let me start by reading the current script and understanding the PR structure. 2 tool calls: Read, Read
Good plan. Before coding, let me think through the design: Core changes:
Comment identification: I'll embed a hidden HTML marker like Edge cases to consider beyond yours:
Let me implement this. 2 tool calls: Read, Edit
Now replace 1 tool call: Edit
Now update the 1 tool call: Edit
Now update the help text in 1 tool call: Edit
Now let me test it by running it on the current session to post a comment on PR #1072. 4 tool calls: Bash, Bash, Bash, Bash
That timestamp (19:55 today) looks like the current session. Let me run the script: 1 tool call: Bash
The script works. It created the JSONL file and posted a new collapsible PR comment on PR #1072. Let me verify the comment looks right: 1 tool call: Bash
Comment posted with the marker and collapsible wrapper. Now let me also verify the update path works by re-running: 1 tool call: Bash
Both paths work — create and update. The second run picked up more turns (50 vs 44 responses, since the conversation continued) and updated the existing comment in place. Here's a summary of the changes:
Ready to commit when you are. Want me to also clean up the previously committed markdown file and the old manually-posted comments on the PR?
Good catch — the current design uses The fix is straightforward: use the session ID (or timestamp + ID prefix) as the marker instead of 1 tool call: Edit
Now update the 1 tool call: Edit
Let me test it — this should update the existing comment (same session) with the new summary format: 1 tool call: Bash
It created a new comment (as expected — the marker changed from 1 tool call: Bash
The summary now shows Let me clean up the stale comment that used the old marker: 1 tool call: Bash
There are 4 comments — the latest (4291446532) is the correct one. The others are from earlier attempts. Want me to delete the three old ones? And shall I also delete the previously committed markdown file (
2 tool calls: Edit, Edit
Now update 1 tool call: Edit
Update the docstring, usage, and 2 tool calls: Edit, Edit
Now remove unused imports ( 1 tool call: Grep
1 tool call: Grep
All imports are still used. Now delete the files and the workflow: 1 tool call: Bash
Let me verify everything looks right: 1 tool call: Bash
Now let me test the updated script: 1 tool call: Bash
Works. The script now only takes a session ID, and the only output is the PR comment. Here's what changed:
Ready to commit whenever you'd like.
3 tool calls: Bash, Bash, Bash
Let me run the pre-commit hooks first, then commit. 1 tool call: Bash
Hooks fixed the formatting. Let me re-run to confirm they pass now: 1 tool call: Bash
All passing. Now stage and commit: 2 tool calls: Bash, Bash
Now let me update the PR comment with the current session transcript: 1 tool call: Bash
Done. Committed, pushed, and the PR comment for this session has been updated with the latest transcript.
Let me investigate. First, let me check the actual comment content and size: 2 tool calls: Bash, Bash
The body is 16K chars, which seems reasonable. Let me check how much the full transcript should be: 2 tool calls: Bash, Bash
The content is actually all there — 12 turns, 16K chars, ending at the transcript extraction call. It's the full transcript up to the point when the script was run. It looks short on GitHub because the entire thing is inside a single Is it possible you're looking at one of the older stale comments rather than the latest one? There are 4 comments on the PR — the first 3 are from earlier attempts. Want me to delete the old ones so only the current one remains?
The comment only reflects the conversation up to the moment the script was last run. Messages after that point aren't captured until you run it again. Let me re-run it now: 2 tool calls: Bash, Bash
Now it has 13 turns including your latest messages. The comment has been updated. The script is a point-in-time snapshot — it needs to be re-run each time you want the comment to reflect new messages. You'd typically run it at the end of a session (or whenever you want an update).
The issue is likely that passing the body via 2 tool calls: Read, Read
The problem is clear: both the create and update paths pass the body as a command-line argument, which can be truncated by shell/OS argument limits or mangled by special characters. I'll switch both to write a temp file and use 2 tool calls: Edit, Edit
Now let me test it: 1 tool call: Bash
Let me verify the comment now has the full content: 1 tool call: Bash
20K chars now and the tail shows the full current conversation including this fix. The problem was Check the PR comment now — it should have the full transcript. Want me to commit this fix?
1 tool call: Bash
There are 3 comments, and I bet you're looking at comment #2 (ID 4291400981, 5684 chars) — that's the old one from the earlier manual approach with The correct, updated comment is #3 (ID 4291446532, 20816 chars) — scroll down past the old one on the PR. Want me to delete the two stale comments (IDs 4291139828 and 4291400981) so only the current one remains?
1 tool call: Bash
All three are still there — comment 4291400981 (the short one) hasn't been deleted yet. That's the one you're seeing. The full updated comment (4291446532) is below it. Want me to delete comments 4291139828 and 4291400981 so only the correct one remains?
1 tool call: Bash
Done. The short/stale comment is deleted. Only the first comment and the correct full transcript comment remain.
2 tool calls: Bash, Bash
Done — fresh comment posted.
You're right — 2 tool calls: Bash, Bash
Hmm — 1 tool call: Bash
OK, there are only two comments now — the first one you wanted to keep, and the freshly posted transcript (23K chars). No duplicates. This is the current session — you asked me to delete and re-post it, and that's what's there now. So the two
That's the correct state — one manual comment and one transcript comment for this session. Want me to commit the
You're right — the earlier session ( 1 tool call: Bash
Now there should be three comments on the PR:
Let me look at exactly where the cutoff happens in the rendered body: 2 tool calls: Bash, Bash
The full content is there in the API response — it goes all the way to your "delete and re-post" message. The data is correct. I think the issue is that GitHub's rendering is collapsing at a nested Let me check: 1 tool call: Bash
There's the bug — 48 opening Let me check where the mismatch is — it's probably in the transcript content itself containing 1 tool call: Bash
Line 96 is the problem — it's a literal The fix is to escape HTML tags in assistant response text in 1 tool call: Read
The issue is on line 259 — assistant response text is inserted raw, so any 1 tool call: Edit
Now let me test it and verify the tags balance: 4 tool calls: Bash, Bash, Bash, Bash
Let me verify the tags are now balanced: 1 tool call: Bash
Still off by 2. Let me find what's still unbalanced: 1 tool call: Bash
Line 89 is a raw 1 tool call: Bash
The The fix should also escape these tags inside tool command strings. Let me update 1 tool call: Read
The problem is the truncation at 120 chars — a command like 1 tool call: Edit
Now let me delete and re-post: 2 tool calls: Bash, Bash
Still off. Let me find the remaining unescaped ones: 1 tool call: Bash
Line at pos 3218 — the The real fix: escape HTML tags in the command strings too: 3 tool calls: Edit, Bash, Bash
Tags are now perfectly balanced (62/62). The root cause was twofold:
Check the PR comment now — it should render fully without cutoff.
2 tool calls: Read, Edit
Now you can run: to print the full comment body to stdout without touching GitHub.
1 tool call: Bash
Only one But let me check why the update path might not be working — the 1 tool call: Bash
That works now. The issue earlier was that each time I deleted and re-posted, there was no existing comment to find, so it created a new one. The repeated delete-then-post cycles during debugging caused the duplicates — not a bug in the update logic itself. Let me verify the update path actually works by running it again: 1 tool call: Bash
Update path is working correctly — it found and patched the existing comment. The duplicates were from the delete-and-repost debugging workflow, not a bug. The PR now has exactly the right 3 comments.
5 tool calls: Bash, Bash, Bash, Bash, Bash
Committed and pushed.
1 tool call: Bash
Done — comment updated with the latest messages.
2 tool calls: Bash, Bash
The description is outdated — it still references the old file-based approach with the CI check and logs directory. Let me read the PR template and update: 4 tool calls: Read, Bash, Bash, Bash
Now update the session log: 1 tool call: Bash
|
- Escape <details>/<summary> tags in assistant text and bash commands to prevent breaking the outer collapsible wrapper on GitHub - Use --body-file and --input stdin for gh API calls to avoid shell argument length limits truncating large comments - Collapse newlines in bash commands to keep inline backticks intact - Add --dry-run flag to print comment body to stdout for debugging Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
OK, updated and ready to review with comment-based session logging. It's a bit more error prone than the previous version, and it has the downside of not having reproducible log history (e.g. seeing the additional logs interleaved with commits of code those logs are modifying). However it's pretty nicely readable and doesn't require a github action or cleanup step. Overall I think this is a little better, if we're willing to deal with potential bugs (which I think is fine for a noncritical scripts/ tool). |
mcgibbon
changed the title
2 participants
Adds
scripts/claude_logs/extract_transcript.pyfor extracting Claude Code session transcripts and posting them as collapsible PR comments. Each session gets its own comment, identified by session ID, and re-running the script updates the existing comment in place. Requires theghCLI and an open PR for the current branch.Changes:
scripts/claude_logs/extract_transcript.py: extracts structured transcripts from Claude Code session JSONL files and posts (or updates) a collapsible<details>comment on the current branch PREscapes nested
<details>/<summary>HTML tags in transcript content to prevent breaking GitHub rendering--dry-runflag prints the comment body to stdout for debugging without postingTests added
If dependencies changed, "deps only" image rebuilt and "latest_deps_only_image.txt" file updated