Computer Use get_app_state hang and relative hook path failure are hard to diagnose
Open 💬 2 comments Opened May 20, 2026 by agentropolis
Summary
Computer Use and hook execution behavior looked inconsistent during a Codex CLI session.
Environment
- Workspace:
/Users/a/code/final-prod-final-prod - Shell: zsh
- OS context: macOS
- Codex hook config path shown in hook output:
/Users/a/.codex/hooks.json
What happened
1. Computer Use get_app_state hung
A Computer Use call was issued with this exact payload:
{
"app": "Safari"
}
The call form was:
await tools.mcp__computer_use__get_app_state({ app: "Safari" });
The call did not return useful state and continued running until interrupted/terminated. The user was checking OTEL logs and believed the args were being sent incorrectly or represented incorrectly.
2. Stop hook repeatedly failed on a missing project-local script
Codex emitted this hook error repeatedly:
/Library/Developer/CommandLineTools/usr/bin/python3: can't open file '/Users/a/code/final-prod-final-prod/.codex/hooks/scripts/hooks.py': [Errno 2] No such file or directory
The global hook config contained commands like:
{
"type": "command",
"command": "python3 .codex/hooks/scripts/hooks.py --hook Stop",
"timeout": 10,
"statusMessage": "Running session stop hook"
}
Because the command is relative, it resolved from the active workspace to:
/Users/a/code/final-prod-final-prod/.codex/hooks/scripts/hooks.py
That project-local path did not exist.
Expected behavior
- Computer Use calls should expose/log the exact structured input passed to MCP tools in a way that matches OTEL traces.
- If hook commands are relative, Codex should make the execution cwd and resolution behavior explicit.
- Hook failures caused by missing project-local scripts should ideally be easier to diagnose, especially when the hook config lives globally.
Actual behavior
- The Computer Use call hung without visible state.
- The user suspected the tool args were wrong or not being reported honestly.
- Stop hook errors repeatedly appeared due to a missing relative script path.
Suggested improvements
- Add explicit debug output or trace IDs for MCP tool payloads when a tool hangs.
- Include hook cwd, config source, resolved command path, and hook name in hook failure messages.
- Consider warning when a global hook config uses a relative project path that does not exist in the current workspace.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗