Rescue a dead ChatGPT thread
Recover a stuck ChatGPT chat where Soil's tools went missing · run the rescue prompt, paste the result into Import, and get a real handover with its own load code.
The problem
In a very long or old ChatGPT chat, ChatGPT can stop exposing the connector's
tools to that specific chat. The model says the Soil tools are not available
here, or that it cannot run soil save. This is a ChatGPT limitation in how it
carries connectors across long chats, not a Soil outage. (See the same
explanation under ChatGPT · if Soil's tools go missing.)
You cannot save from inside that thread the normal way. But if the thread still
holds context you can't easily recreate, you can rescue it: have ChatGPT write
the save out as text, then paste that text into Soil's Import page out of band.
It becomes a normal handover with its own #NNN load code.
Rescue it
Open Import
Go to console.nativesoil.dev/handovers and click Import, or go straight to console.nativesoil.dev/handovers/import.
Copy the rescue prompt
The Import page shows the prompt below and a copy button. It's the exact prompt
to paste into the stuck thread. This is rendered from the single source of truth,
@soil/rescue-prompt (the same constant the Import page uses), so it can never
drift from the live prompt:
Produce a SAVE of everything important in THIS conversation so it can be reloaded into a fresh AI session. Output ONE fenced ```json code block and nothing else (no text before or after).
The JSON object must have EXACTLY these top-level keys and no others:
- "projectId": a short stable slug for the project (lowercase, hyphens), e.g. "billing-rework"
- "title": a short human title for this save
- "extractionSections": an object containing ALL 17 of these keys, in this order:
projectIdentity, decisions, workflow, architecture, constraints, rejectedPaths,
executiveSummary, currentTask, latestUserIntent, sessionDelta, blockers, nextSteps, openQuestions,
sessionActivity, restoreInstructions, provenanceMap, safetySummary
What each section holds (fill EVERY one from this conversation):
- projectIdentity: what the project is, its purpose, who it is for, the project's own working language (its named concepts and terms with their agreed meanings — enumerate them, do not sample), and how the user likes to work.
- decisions: ENUMERATE every settled decision with its reasoning, even ones decided long ago. List them all; do not summarise them away.
- workflow: how the work is run, the review/done rules, and the standing "always do X / never do Y" corrections.
- architecture: the durable shape of the system or work and how the parts fit (by name, never private absolute paths).
- constraints: the hard invariants this project must never violate, each with why it binds.
- rejectedPaths: what was tried or considered and deliberately discarded, and why.
- executiveSummary: one screen orienting a cold reader: what this is, where it stands, the single most important next thing.
- currentTask: the task in flight, the approach and why, how far along, what "done" looks like, plus the live current status.
- latestUserIntent: the last substantive direction the user gave, in their own words; it overrides any stale earlier plan.
- sessionDelta: what changed this session versus where it started (decided, built, reversed, learned, unblocked).
- blockers: what is blocking progress, what was tried, and the dependency it imposes.
- nextSteps: the concrete, ordered next actions, specific enough to start immediately.
- openQuestions: what is genuinely still undecided, so the next model does not assume.
- sessionActivity: the consequential actions taken this session and their outcomes (meaning only, never raw logs).
- restoreInstructions: ONE paste-ready, standalone boot prompt covering the WHOLE working state so a cold model can continue with the smallest practical loss of operationally important state; state known or suspected omissions instead of implying completeness.
- provenanceMap: where the load-bearing claims came from and how confident you are; never present a guess as verified.
- safetySummary: anything you withheld for safety; say that it exists and where it is configured, never its value. "none" if nothing.
Rules:
- Each section value is a single plain-prose string. If a section genuinely does not apply or you have nothing for it, set that key to the object {"status":"missing","summary":null} instead of a string.
- SELF-CONTAINED IS THE RULE: assume the reader has ONLY this block, no repo, no docs, no links, no earlier thread. INLINE the content in every section. Never point outward, no "see the repo", "in the docs", "refer to the file", or a bare link, in ANY section; if the reader would have to fetch something, paste it in instead.
- Write about the PROJECT, not about the act of saving. The save itself is not a decision, task, or next step.
- Do NOT include any secrets, API keys, tokens, passwords, or private absolute file paths. They will be rejected.
- Output ONLY the ```json block.Paste it into the stuck thread
Paste the prompt as a new message in the dead ChatGPT thread. ChatGPT replies
with one fenced json block · that's the save, written out as text.
Copy ChatGPT's reply
Copy the whole json block ChatGPT produced, fences and all.
Paste it into Import
Back on the Import page, paste the block into the import field and click
Import. Soil ingests it through the same safe save path as a normal save, so
it lands as a real handover with its own #NNN load code · loadable in any
client, exactly like one you saved with soil save.
A rescue is still bounded by what ChatGPT can still read in that thread · if
the thread has dropped earlier context, the rescue can only capture what
remains. Saving early under stable #names is always better than rescuing
late. And the receipt rule holds: a real import shows a #NNN; if it doesn't,
it didn't save. Don't paste any secrets · they're rejected.
When to rescue vs start a new chat
If you can recreate the context yourself, just
start a new chat · the tools return immediately · and
run soil save there. That's the simpler path.
Rescue-import is for the case where the thread holds context you can't easily recreate: a long debugging session, a sequence of decisions, a structure you worked out turn by turn. Then it's worth one round-trip to get that out as a handover before the thread is gone for good.