Problem

When using Goose programmatically via the API in long-running applications (e.g., Slack bots), MCP processes accumulate indefinitely and are never cleaned up, causing memory leaks that eventually lead to OOM crashes.

Evidence

In our Kubernetes-deployed Slack bot, we observe:

• Linear memory growth corresponding to each new Slack thread interaction
• Multiple instances of the same MCP servers accumulating (6+ copies of each configured MCP server)
• Memory never decreases - processes persist until pod restart
• Each new conversation thread spawns a complete new set of MCP processes

Current Behavior

1. Each session spawns new MCP processes via ExtensionManager
2. Sessions created via API persist indefinitely
3. No mechanism exists to clean up sessions or their associated MCP processes
4. The `ChildWithCleanup` Drop trait is never triggered because Extension objects are never removed from the ExtensionManager

Proposed Solution

Add a session cleanup API endpoint that:

• Removes the session from memory
• Cleans up associated extensions and MCP processes
• Properly triggers Drop implementations to terminate child processes

Suggested endpoint: `DELETE /agent/session/{session_id}`

Use Case

This primarily affects:

• Long-running bot deployments (Slack, Discord, etc.)
• Any programmatic API usage where the client persists across multiple sessions
• Kubernetes/containerized deployments where memory limits are enforced

The issue doesn't occur in CLI usage because the process terminates after each task, triggering automatic cleanup.