TPEE Toptronic® Prompt Engineering Editor

89. Why You Should Limit Your LLM to: Work Only Inside the Working Directory

Understand why every long-project session must instruct the LLM to restrict its work to the project's working directory, and what damage an unbounded instruction set invites.

By Jacques Botte, founder of Toptronic®. Last updated 19 September 2026.

The lesson

An LLM in a coding session is an eager executor. If you say "create this file" without saying where, it will pick a location for you — the current folder, the home directory, or wherever its tools happen to default to. If you say "clean up the project" without a boundary, "the project" means whatever it inferred. The single most effective guard you can write is a one-line instruction at the top of your prompt: work only inside `C:\...\My_Working_Directory`, never create, modify, or delete anything outside it.

The reason is containment of error, not distrust. Models make reasonable-looking but wrong choices all the time, and file placement is one of them. An assistant that helpfully "tidies up" a folder it was never meant to touch can destroy work in a neighbouring project. An assistant that writes a download into Downloads instead of the project breaks the chain of custody that lesson 88 established. A boundary converts those mistakes from project-wide incidents into trivial non-events, because everything it can touch is inside the box.

The second reason is predictability of the project state. When every file the LLM created or changed is guaranteed to be inside one directory, the directory is a complete picture of the work. You can diff it, back it up, commit it to git, or hand it to the next session and know you have everything. The moment writes can escape the boundary, the folder becomes a partial picture, and your inventory files, backups, and handovers quietly start lying to you.

Third, a bounded scope makes instructions sharper. "Update the docs in the working directory" forces both you and the model to be explicit about which docs, which folder, which naming convention. You get better engineering out of the model not because it is smarter, but because the constraint removes ambiguity. Vague scope produces vague work; a path anchor produces anchored work.

Fourth, the boundary is what makes the Toptronic® conventions enforceable. The history files, the inventory, the directory-structure document, and the handover all assume the working directory is the whole world of the project. If the model can write elsewhere, those records become incomplete and the whole convention system degrades. One line in the prompt is what keeps the paperwork honest.

How to phrase it matters. The instruction should be affirmative and absolute: "All work — file creation, edits, deletes, and saves — must occur inside `<path>`. Do not write to any location outside this directory, including your default folders." Prefer a literal path over "the project folder", because the model cannot guess which folder you mean. For extra safety on destructive tasks, add "before deleting or moving anything, list the planned changes and wait for my go-ahead."

A boundary also protects you on the read side. Reading outside the directory is less dangerous than writing, but it is still worth controlling: reading random folders can pull unrelated or private content into the session's context, and from there into files, logs, and history records. If the session only needs the project, tell it so — "read only within the working directory" — and the context stays clean and small.

Note the honest limit: an instruction is a convention, not a sandbox. The model generally follows it, and well-behaved coding tools respect it, but only file-system permissions and backups truly guarantee containment. So keep real backups, and keep the working directory away from folders holding personal data. The instruction line reduces the probability of accidents to near zero; backups reduce the cost of the remainder.

Make it a standing rule, not a per-session afterthought. Put the line in your project's standard prompt header, in your rules file, and in the first message of every session, exactly as the Toptronic® LLM Rules do with `WORKING_DIRECTORY_AND_PATH`. Combined with lesson 88's dedicated folder, this one habit removes the most common class of long-project accidents before they can happen.

Check yourself

Question 1: What happens if you say "create this file" without telling the LLM where?
  1. The LLM always asks and refuses to proceed without an absolute path
  2. The LLM picks a location for you — a default or inferred folder — which may not be your project at all — correct
  3. The file is created in every directory simultaneously
  4. The operating system chooses a secure system folder

Answer: The LLM picks a location for you — a default or inferred folder — which may not be your project at all

Without a path anchor, the model writes where its tools default to or where it infers the project lives, breaking the chain of custody that the working directory establishes.

Question 2: Why does limiting work to the working directory keep your project records honest?
  1. Because the LLM is forbidden from keeping notes
  2. Because when every write is inside one directory, that directory is a complete picture — so backups, inventories, and handovers describe the whole truth — correct
  3. Because files outside the directory are automatically deleted
  4. Because git cannot work with multiple folders

Answer: Because when every write is inside one directory, that directory is a complete picture — so backups, inventories, and handovers describe the whole truth

If writes can escape the boundary, the folder becomes a partial picture and the inventory, backups, and history files quietly become incomplete.

Question 3: What is the honest limitation of the "work only inside the working directory" instruction?
  1. LLMs can never follow it
  2. It is a convention, not a sandbox — real containment ultimately comes from file-system permissions and backups — correct
  3. It only works on Linux
  4. It requires paid tools to enforce

Answer: It is a convention, not a sandbox — real containment ultimately comes from file-system permissions and backups

The instruction reduces accidents to near zero, but only actual permissions and backups guarantee containment — which is why both are part of the same habit.

← Previous lesson · All 91 lessons · Next lesson →

The full course — 91 lessons and 273 quiz questions — ships inside the app. Get TPEE to study it offline.