Computer Use get_app_state hang and relative hook path failure are hard to diagnose

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.