Fix 400 prompt-too-long errors from duplicate session pruning in pi-coding-agent extension
Session from 0xKobolds on Hugging Face by moikapy · MIT · condensed by Coders Talk
Investigate and fix recurring 400 'prompt too long' API errors that started after adding a session pruning extension, then rationalize the session architecture and fix related type errors and plan/build mode tool restrictions.
- +0Prompt · +0This started happening more since you added the session pruning extension, can you investigate it?
- +0mAgent did · +0mExplored codebase for session pruning extension, gateway, LLM providers and pi-coding-agent internals looking for source of an unspecified error
- +1mPrompt · +1mYou get 400 prompt too long and it started happening after you added in the session prune extension
- +1mAgent did · +1mFound root cause: session-pruning-extension only warned about context size but never removed messages, bypassing pi-coding-agent's built-in compaction; removed the extension from pi-config.ts and index.ts
- +2mPrompt · +2mDo we need both extensions, our session manager was first and then you copied the pruning extension from the pi monorepo
- +2mAgent did · +2mDiscovered both session-manager and session-pruning stored messages in separate, unsynced SQLite databases; removed session-manager too but had to restore it after finding task-manager, multi-channel and agent-registry depended on KOBOLD_SESSION_ID it set
- +7mPrompt · +7mLet's stay clean, secure and private
- +7mAgent did · +7mSet PI_CODING_AGENT_DIR to point pi-coding-agent's native session storage at ~/.0xkobold, removed session-pruning and session-manager extensions, created a session-bridge extension using ctx.sessionManager.getSessionId(), and rewired task-manager, multi-channel and agent-registry to use native session IDs instead of the custom KOBOLD_SESSION_ID env var
- +16mPrompt · +16mCan you investigate type errors and properly fix them, and look into how plan mode works because I thought you were still able to make edits before asking me to go into build mode
- +16mFail · +16mbun run build surfaced multiple TypeScript errors across session-bridge, task-manager and other extensions from the workspace/sessionId rename churn
- +16mAgent did · +16mFixed type errors (task manager field renames, missing tool schema properties), and found mode-manager was listening on a nonexistent 'before_tool_call' event instead of 'tool_call', which meant plan mode never actually blocked edit tools; fixed the event name and confirmed plan mode now blocks write/edit/execute_shell while build mode allows them
- Break · 42m away, not counted
- +21mOutcome · +21mBuild passes clean (tsc), duplicate session storage removed, single native session ID flows through task-manager/multi-channel/agent-registry, and plan mode now correctly blocks write_file/edit_file/search_and_replace/execute_shell while build mode allows them
Next time I'd open with the exact error text (400 prompt too long) instead of a vague 'this started happening' so the agent doesn't spend a dozen turns grepping blindly. The correction that actually moved things forward was pushing back on 'do we need both extensions' — that's what surfaced the duplicate SQLite databases and the KOBOLD_SESSION_ID dependency chain the agent hadn't traced. Catching that plan mode was listening on a nonexistent event was a good save; that bug meant plan mode never blocked anything the whole time.