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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗