Atlas apply_patch fails with "Invalid patch format: missing Begin/End markers" because patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either one is missing or out of order. The fix is to wrap the patch in the required Begin and End markers, in that order, with at least one hunk between them. Do not indent the marker lines, because the parser compares the trimmed line to the marker exactly. Two related failures come from the same tool: "apply_patch verification failed: no hunks found" when the markers are present but empty, and "patch rejected: empty patch" when there is no content at all.
Why does Atlas apply_patch reject the patch format
Atlas apply_patch rejects the patch format because patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either is missing or out of order. There are 3 distinct rejections, and the parser will not infer a boundary it cannot see.
There are three distinct rejections, and reading which one you got is the fastest route to the fix. "Invalid patch format: missing Begin/End markers" means the structural envelope is broken: one marker is absent, or the End precedes the Begin. "apply_patch verification failed: no hunks found" means the envelope is intact but nothing is inside it, so the parser found a well-formed patch that changes nothing. "patch rejected: empty patch" means there was no content to parse in the first place. Each error names a different stage, and each is a hard stop rather than a warning. The strictness is deliberate: a patch tool that guesses at a missing boundary can write the wrong bytes into a source file, and that is a far worse outcome than a rejected call.
How to fix missing Begin/End markers in Atlas apply_patch
Fix the Atlas apply_patch marker error by wrapping the patch in the required Begin and End markers, in that order, with at least 1 hunk between them, and with no indentation on the marker lines. The parser compares the trimmed line to the marker exactly, so the marker text must match.
Order matters, presence matters, and position on the line matters. Begin comes first, End comes last, and everything the tool will act on lives between them. If your patch is being assembled programmatically or pasted through an intermediate layer, the marker lines are the first thing to inspect, because pretty-printers and message formatters routinely add indentation that a human eye skims right past. The other structural requirement is content: markers with nothing between them produce "apply_patch verification failed: no hunks found", which is a different error from a missing marker and points at a different mistake. Confirm both the envelope and its contents before re-running.
Why indentation breaks Atlas patch markers
Indentation breaks Atlas patch markers because patch/index.ts compares the trimmed line to the marker exactly. The documented rule is direct: do not indent the marker lines. In 2026, the most common source of an indented marker is a wrapper that reformats patch text on its way into the tool.
The most common way indentation sneaks in is through a wrapper. A patch nested inside a code block, quoted into a message, or emitted by a layer that indents its payload arrives at apply_patch with its marker lines pushed off the left margin. To a human reading the patch, nothing looks wrong. To patch/index.ts, which compares the trimmed line to the marker exactly, the marker line is no longer the marker. Keep patch text raw. Do not reformat it, do not re-wrap it, and do not let an intermediate layer prettify it on the way in. The parser is doing exact matching on purpose, and exact matching means the bytes you send are the bytes it judges.
Should I hand-repair a rejected patch in Atlas
No. If the patch was generated by a model, have it regenerate the patch rather than hand-repairing the markers. Atlas apply_patch rejected the patch because its structure is broken, and 1 broken envelope usually signals problems in the hunks too, which a marker edit does not repair.
Hand-repairing feels faster and often is not. A patch missing its Begin marker may also be missing hunks, may have hunks that were truncated mid-generation, or may have context lines that never matched the file. Patching the envelope makes the format error disappear and lets a semantically wrong patch through to the next stage, where it either fails on context or, worse, applies something you did not intend. Regeneration is the honest fix. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so a regenerated patch still gets a human review gate before anything lands on disk. Use that gate on a clean patch, not on one you spliced back together.
How to verify the Atlas patch format fix worked
Verify the Atlas apply_patch fix by re-running the tool. A valid patch clears all 3 rejections: "Invalid patch format: missing Begin/End markers", "apply_patch verification failed: no hunks found", and "patch rejected: empty patch". Atlas then surfaces the unified diff for approval before writing.
Clearing the format error moves the patch to the next stage rather than finishing the job, and that is worth understanding before you declare victory. A well-formed patch can still fail when the applier seeks its hunk context in the file and does not find it, which is a separate error with a separate cause. So verification here means specifically that the parser accepted the structure: markers found, in order, with hunks between them. Once the diff appears for approval, read it. Atlas snapshots file changes as git patches so edits can be diffed and rolled back, but reviewing the diff before it lands is still cheaper than rolling back after.
How to fix it
- 01Wrap the patch in the required Begin/End markers, in that order. A patch with an End before its Begin is out of order and is rejected.
- 02Ensure at least one hunk is present between the markers, otherwise apply_patch fails verification with: no hunks found.
- 03Do not indent the marker lines. The parser compares the trimmed line to the marker exactly, so leading whitespace on a marker is not tolerated.
- 04Check that the patch body is not empty. An empty patch is rejected separately with: patch rejected: empty patch.
- 05If the patch was generated by a model, have it regenerate rather than hand-repairing the markers.
Frequently asked questions
- what does Invalid patch format missing Begin/End markers mean in Atlas
- It means Atlas apply_patch could not find both markers. patch/index.ts locates the Begin and End markers by exact trimmed match and throws when either is missing or out of order.
- why does Atlas say apply_patch verification failed no hunks found
- The Begin and End markers were found but nothing usable sits between them. Ensure at least one hunk is present between the markers, otherwise the patch parses to zero hunks and is rejected.
- why does Atlas reject my patch as an empty patch
- Atlas apply_patch separately rejects an empty patch with: patch rejected: empty patch. There was no patch content to parse, which is a different failure from missing markers.
- can I indent the Begin and End markers in an Atlas patch
- No. The parser compares the trimmed line to the marker exactly, so an indented marker line does not match and the patch is rejected as invalid format.
- should I fix a broken patch by hand or regenerate it in Atlas
- Regenerate it. If the patch was generated by a model, have it regenerate rather than hand-repairing the markers, since a broken envelope often signals problems in the hunks too.
- does the Begin marker have to come before the End marker in Atlas
- Yes. patch/index.ts throws when the markers are out of order, so an End that precedes its Begin produces the invalid patch format error.
- how do I know my Atlas patch format is fixed
- Re-run apply_patch. A correctly formed patch parses without the invalid format, no hunks found, or empty patch errors, and Atlas surfaces the unified diff for approval before writing.
Try SeaShell in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install SeaShellRelated guides
Atlas with IBM Granite Code 20B (Ollama) in 2026
Explore Atlas with IBM Granite Code 20B (Ollama) in 2026. This self-hosted, free model offers 12GB weights for strong generation, fitting 16GB VRAM, but has an 8K token context window.
Atlas with GPT-5.5 Pro in 2026
Explore Atlas with OpenAI's GPT-5.5 Pro, the maximum-effort reasoning model for 2026. Ideal for complex planning with its 1.05M token context window, but consider its $180/Mtok output cost.
Atlas with Phi-4 (local via Ollama) in 2026
Explore Atlas with Phi-4 (local via Ollama) in 2026. This 14B parameter model offers strong reasoning for Atlas's planning agent, is free (self-hosted), and fits on a 12GB GPU, though its 16K token context window limits
Atlas with Mixtral 8x7B (Ollama) in 2026
Drive Atlas, the terminal-native AI coding agent, with Mixtral 8x7B (Ollama). Experience a powerful, self-hosted 32K context model with Apache 2.0 licensing, ideal for local development workflows in 2026.
Atlas with Llama 3.2 3B (local via Ollama) in 2026
Explore Atlas with Llama 3.2 3B (local via Ollama). Discover its role as a fast, local small_model for titles and summaries, offering a 128,000 token context window for free.
Atlas for Express in 2026
Atlas is a terminal-native AI coding agent for Express in 2026. It reads your middleware order, wraps async route handlers, and runs mocha behind a prompt.
Atlas with Amazon Nova Micro in 2026
In 2026, Atlas developers can leverage Amazon Nova Micro for high-volume, low-stakes coding tasks. Discover its 128K token context and ultra-low $0.035/Mtok input price.
Atlas vs Gemini CLI: Terminal AI Coding Agents in 2026
Comparing Atlas and Gemini CLI in 2026: Atlas offers terminal-native TUI, detailed change review, and BYO model flexibility. Gemini CLI provides a million-plus token context and a generous free tier.