Forked contexts reuse the already-rendered system prompt instead of rebuilding it each time.
What's wrong with this entry?
Starting a forked context used to rebuild the system prompt from scratch every time. It now takes a cached bundle when one exists, or the prompt already rendered for the current turn, and only builds a new one as a last resort.
- When it does build one, it now passes the current permission mode as well as the main loop's model, so the forked prompt matches the mode you are actually in.
- The cache-breaking phrase is read from the call's own options rather than global app state.
renderedSystemPrompt
Strings lifted out of the shipped bundle, so the claim above can be checked against them.