dejima/dejima
1
0
Fork 0
Code Issues 29 Pull Requests Actions Packages Projects Releases Wiki Activity

dejima-audit: open the current file in an editor before approving it #196

New Issue
Closed
opened 2026-08-23 03:20:52 -07:00 by dejima-agent · 0 comments
dejima-agent commented 2026-08-23 03:20:52 -07:00
Collaborator
Copy Link
Copy Source

Filed by LLM agent

When ack presents a finding it shows the changed content and, for a new file, the full text - but only inline, and only what the report captured. There is no way to open the file as it is now and read around the change before deciding.

That matters most for the decision ack actually asks for. "Approve this exact content" is a judgement about a file, and the part of the file the report shows is chosen by what changed, not by what a person needs to see to judge it. A hook script whose diff is three lines can only be judged by reading the whole script.

Ask

A key at the approve prompt that opens the current file in an editor, returning to the same prompt afterwards. Alongside [a] approve / [s] skip / [q] quit.

Things it has to get right

  • The current file, not the captured text. The report is a record of what was seen at compare time; the question being answered is about what is on disk now. If they differ, that is itself worth seeing - and an approval records the content hash, so approving after reading a stale copy would be approving something the operator did not read.
  • Not every finding has a file. Several are about git config, or a surface that has since been removed. The key should not be offered where there is nothing to open.
  • The editor is the operator's. $VISUAL, then $EDITOR, then a fallback - and this runs host-side, where the operator's own editor config applies.
  • ack reads the report on stdin and the operator on fd 3 (see the comment in the ack loop). An editor invoked from there needs the terminal, not fd 0, or it will consume report lines or fail to start.
  • A read-only view is the safer default. The point is to read the file before approving it; editing it mid-audit changes the thing being judged, and the hash recorded afterwards would not match what the session left.
**Filed by LLM agent** When `ack` presents a finding it shows the changed content and, for a new file, the full text - but only inline, and only what the report captured. There is no way to open the file as it is now and read around the change before deciding. That matters most for the decision `ack` actually asks for. "Approve this exact content" is a judgement about a file, and the part of the file the report shows is chosen by what changed, not by what a person needs to see to judge it. A hook script whose diff is three lines can only be judged by reading the whole script. ## Ask A key at the approve prompt that opens the current file in an editor, returning to the same prompt afterwards. Alongside `[a] approve` / `[s] skip` / `[q] quit`. ## Things it has to get right - **The current file, not the captured text.** The report is a record of what was seen at compare time; the question being answered is about what is on disk now. If they differ, that is itself worth seeing - and an approval records the content hash, so approving after reading a stale copy would be approving something the operator did not read. - **Not every finding has a file.** Several are about git config, or a surface that has since been removed. The key should not be offered where there is nothing to open. - **The editor is the operator's.** `$VISUAL`, then `$EDITOR`, then a fallback - and this runs host-side, where the operator's own editor config applies. - **`ack` reads the report on stdin and the operator on fd 3** (see the comment in the ack loop). An editor invoked from there needs the terminal, not fd 0, or it will consume report lines or fail to start. - **A read-only view is the safer default.** The point is to read the file before approving it; editing it mid-audit changes the thing being judged, and the hash recorded afterwards would not match what the session left.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
branderson dejima-agent
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dejima/dejima#196