Python: [Bug]: LocalShellTool never executes on a self-hosted Foundry agent since openai 1.14.4 - "No tool output found for shell call"

[alkaiserItron]

Description

Here is my setup: a self-hosted Foundry agent (create_harness_agent + FoundryChatClient, served via
ResponsesHostServer) that uses a LocalShellTool as its shell_executor to run commands locally
against a per-session sandbox environment. Local execution is required here because the shell has to read files
staged into the agent's own container.

This worked until recently. On agent-framework-openai 1.14.4 every turn that makes a shell call
now fails with:

400 - No tool output found for shell call call_XXXX (invalid_request_error, param: input)

The command never runs and no output is produced, so the next turn replays a shell call with no
matching output and Foundry rejects it.

After further investigation, I bisected it to the openai package: 1.14.3 works, 1.14.4 fails, with nothing else changed.

My hypothesis is that PR #8294 tightened how a shell call is routed to local execution - it now appears to require the model's response to explicitly mark the call as a local environment. The direct OpenAI Responses API provides that marker, but the self-hosted Foundry path does not, so our local shell call is no longer recognized as local and is never executed.

Request: allow a LocalShellTool registered via shell_executor to keep executing locally on the Foundry-hosted path (for example, by recognizing it as local from the registered tool itself rather than relying on a marker echoed back in the response).

Code Sample

# Self-hosted Foundry agent with a LOCAL shell tool over a sandbox environment.
shell = LocalShellTool(
    mode="persistent", workdir=run_dir, confine_workdir=True,
    approval_mode="never_require", acknowledge_unsafe=True,
)
agent = create_harness_agent(
    client=FoundryChatClient(project_endpoint=..., model=..., credential=DefaultAzureCredential()),
    shell_executor=shell,
    default_options={"store": False, "allow_multiple_tool_calls": True,
                     "reasoning": {"effort": "medium"}},
)
ResponsesHostServer(agent).run()
# The model emits a shell call; on Foundry the returned item has no environment.type=="local",
# so it's classified as hosted, never executed, and the next turn 400s:
#   "No tool output found for shell call call_...".

Error Messages / Stack Traces

agent_framework.exceptions.ChatClientException: ("<class 'agent_framework_foundry._chat_client.FoundryChatClient'> service failed to complete the prompt: Error code: 400 - {'error': {'message': 'No tool output found for shell call call_mbwifqr3HxAGTYoeGam1uMuG.', 'type': 'invalid_request_error', 'param': 'input', 'code': None, 'request_id': 'f35dc6b537d024df6d4a624692a807cb'}}", BadRequestError("Error code: 400 - {'error': {'message': 'No tool output found for shell call call_mbwifqr3HxAGTYoeGam1uMuG.', 'type': 'invalid_request_error', 'param': 'input', 'code': None, 'request_id': 'f35dc6b537d024df6d4a624692a807cb'}}"))

Package Versions

agent-framework-core: 1.19.0, agent-framework-openai: 1.14.4 (broken; 1.14.3 works), agent-framework-foundry: 1.13.1, agent-framework-foundry-hosting: 1.0.0b260918, agent-framework-tools: 1.0.0b260918, agent-framework-monty: 1.0.0b260918

Python Version

Python 3.11.16

Additional Context

• Bisected to agent-framework-openai: 1.14.4 fails, 1.14.3 works (only that package changed; core 1.19.0, foundry 1.13.1, and the *-hosting/tools/monty b260918 builds held constant).
• Suspected change: PR Python: Separate hosted and local shell calls #8294 "Separate hosted and local shell calls" (Python: Separate hosted and local shell calls #8294), the first release of which is openai 1.14.4. It added the is_local_environment gate in _chat_client.py described above.
• Pinning to openai==1.14.3 is our current workaround, but it holds the whole openai package
  back. We want to keep using LocalShellTool against a sandbox on a self-hosted Foundry agent.
• The distinction matters: this really IS a local shell tool executing locally against the
  sandbox — it should take the local execution path, but the new gate misclassifies it as a
  hosted shell call because the Foundry response doesn't carry environment.type == "local".

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: python/packages/openai/agent_framework_openai/_chat_client.py::_shell_item_to_contents at lines 2384-2387 routes a valid unmarked shell_call to informational content when Foundry’s inherited client has a registered local executor. The trigger is a Foundry response containing id, call_id, and commands but no environment. Configure a local shell executor, return that response from the first mocked provider call, and observe that the executor remains untouched and no continuation request is made.

• Failing test: python/packages/openai/tests/openai/test_openai_chat_client.py::test_foundry_shell_call_without_environment_uses_registered_local_executor
• Files examined: python/packages/openai/agent_framework_openai/_chat_client.py, python/packages/openai/tests/openai/test_openai_chat_client.py, python/packages/foundry/agent_framework_foundry/_chat_client.py, python/packages/openai/pyproject.toml, docs/specs/004-python-function-calling-loop.md
• Tests run: test_local_shell_tool_requires_approval_before_function_loop_execution, test_response_content_creation_with_shell_call_remains_hosted_with_local_tool, test_foundry_shell_call_without_environment_uses_registered_local_executor
• Reported version: 1.14.4
• Current version: 1.14.4