[Feature]: Support reusable execution sessions for Responses tools like code interpreter and shell

[RohanSogani]

Problem Statement

Some Responses tools are not fully stateless.

Tools like code_interpreter and shell need a reusable execution session behind the scenes. In one deployment, this is backed by OpenAI-compatible container lifecycle APIs. A request may need to:

• use a container/session explicitly provided by the client
• reuse one from earlier history when the request says auto
• check whether an old container/session is still valid
• create a new one if the old one is missing or expired

Today SMG has strong support for Responses routing, history, MCP calls, and streaming. But there is no clear generic place in the runtime to do this session/container setup once and then reuse it for the
rest of the request.

Without that, this logic has to stay outside SMG or get mixed into tool-specific paths.

Proposed Solution

Add a generic mechanism in SMG to support tools that need a reusable execution session.

At a high level, SMG should support:

1. A hook in the Responses flow to set up tool state before MCP execution starts.
2. A generic interface for a backend to:
   • find an existing session/container
   • validate it
   • create one if needed
3. A way to store that result in request context so later MCP tool calls can reuse it.
4. The same behavior for both non-streaming and streaming Responses.

The important part is that this should stay generic in upstream SMG.

SMG should not hardcode OCI-specific auth, headers, or container APIs. OpenAI-compatible container lifecycle calls are just one example of a backend implementation.

Alternatives Considered

Put container/session lifecycle into MCP tools

This does not seem like the right layer. The model should call tools like execute_python_code or execute_shell_commands, not infrastructure operations like create_container.

Keep all lifecycle logic outside SMG

This works short term, but it means Responses routing is in SMG while session/container handling stays elsewhere. That makes migration incomplete and harder to maintain.

Hardcode OpenAI container behavior in SMG core

This would be too specific. The upstream feature should be generic so different backends can plug in their own session/container logic.

Feature Area

MCP (Model Context Protocol)

Affected Component(s)

mcp

Use Case

We are migrating a Responses runtime where code interpreter and shell currently rely on reusable execution environments.

One concrete backend uses OpenAI-compatible container APIs, but the same pattern also applies to shell sessions and similar tool setups.

What we need from SMG is a generic runtime capability so these tools can:

• reuse prior execution state when possible
• create it when needed
• keep MCP tools focused on execution only
• work the same way in streaming and non-streaming responses

Priority to You

Critical / Blocking

Contribution

• I am willing to contribute this feature (with guidance)
• I am willing to help test this feature
• I can provide more detailed requirements if needed

Additional Context

Suggested ownership split:

Upstream SMG

• add the generic runtime hook/interface
• carry the resolved session/container through the request
• support both streaming and non-streaming flows

Downstream / deployment-specific implementation

• actual container/session client
• auth and trusted headers
• backend-specific validation rules
• mapping session/container info into MCP requests