Mood: 😔
Category: General
The built-in editor canvas (type="editor") silently reformats markdown on save and re-writes its dirty buffer back to disk whenever the file changes externally, making it impossible to discard the formatter-induced changes with git checkout / git reset --hard while the canvas is open.
Repro
- Open a markdown file with aligned-pipe tables (e.g.
| Foo | Bar | with column padding) via the editor canvas.
- The canvas reformats and saves on open/first-save, collapsing the aligned pipes to compact
| Foo | Bar |. The file becomes M in git.
- Run
git checkout -- <file>.
- Within ~1 second the canvas re-writes its in-memory (reformatted) buffer back to disk. The file is
M again.
- There is no
close/save/discard action exposed by the editor canvas (only open), so an agent cannot break the loop programmatically — the user has to find the visible tab and close it manually. If the tab isn't visible (e.g. user has switched the side panel to Changes), neither side can recover.
Evidence
Chasing a clean main checkout, hit it five times in a row:
checked out at 16:39:43
---5s later---
M docs/architecture/some-doc.md
mtime: 16:39:44 ← rewritten 1s after the checkout
The diff was 179 lines of pure whitespace-in-table-cells changes:
-| | |
-| ---------------- | -------------------- |
-| **Foo** | bar bar bar |
+| | |
+| --- | --- |
+| **Foo** | bar bar bar |
The repo had no .prettierrc, no .editorconfig, no markdown formatter in package.json, and no VS Code workspace settings — so the reformat is coming from the editor canvas itself, not the project. Only closing both the canvas tab AND the same file's tab in VS Code let the checkout stick.
Three sub-bugs
- Editor canvas autoformats markdown on save. Should be off by default (or at least opt-in / surface-controlled). Whitespace-only diffs on docs files are noisy and clobber whatever table-formatting style the repo uses.
- No
close / save / discard action on the editor canvas. list_canvas_capabilities returns "actions": []. The agent can open_canvas but cannot close it or drop the buffer — so when a user can't find the visible tab, neither side can recover.
- Canvas re-writes its dirty buffer when the file changes externally. When
git rewrites the file from under the canvas, the expected behavior is "file changed on disk, reload?" (or silent reload if the buffer was clean). Instead the canvas saves its buffer over the external change. This is the actual loop-creator.
Expected
- Markdown reformatting on save should be opt-in.
- The
editor canvas should expose a close action (and probably save / discard) so agents can clean up state they created.
- The canvas should detect external file modifications and either reload or prompt — never silently overwrite.
Environment
| Field |
Value |
| App version |
0.2.24 |
| OS |
Windows 10.0.26200 |
| Theme |
GitHub |
| Path |
/chat |
| Tenure |
Week 12 |
Mood: 😔
Category: General
The built-in editor canvas (
type="editor") silently reformats markdown on save and re-writes its dirty buffer back to disk whenever the file changes externally, making it impossible to discard the formatter-induced changes withgit checkout/git reset --hardwhile the canvas is open.Repro
| Foo | Bar |with column padding) via the editor canvas.| Foo | Bar |. The file becomesMin git.git checkout -- <file>.Magain.close/save/discardaction exposed by theeditorcanvas (onlyopen), so an agent cannot break the loop programmatically — the user has to find the visible tab and close it manually. If the tab isn't visible (e.g. user has switched the side panel to Changes), neither side can recover.Evidence
Chasing a clean
maincheckout, hit it five times in a row:The diff was 179 lines of pure whitespace-in-table-cells changes:
The repo had no
.prettierrc, no.editorconfig, no markdown formatter inpackage.json, and no VS Code workspace settings — so the reformat is coming from the editor canvas itself, not the project. Only closing both the canvas tab AND the same file's tab in VS Code let the checkout stick.Three sub-bugs
close/save/discardaction on theeditorcanvas.list_canvas_capabilitiesreturns"actions": []. The agent canopen_canvasbut cannot close it or drop the buffer — so when a user can't find the visible tab, neither side can recover.gitrewrites the file from under the canvas, the expected behavior is "file changed on disk, reload?" (or silent reload if the buffer was clean). Instead the canvas saves its buffer over the external change. This is the actual loop-creator.Expected
editorcanvas should expose acloseaction (and probablysave/discard) so agents can clean up state they created.Environment