codex monitor setup can silently launch unmonitored sessions when the shim is symlinked or bypassed

[kimyuujin]

Environment

• agmsg: main @ 04fea8f
• codex-cli: 0.144.3
• OS: Ubuntu 24.04 (Termux PRoot, aarch64)

Summary

The Codex monitor setup has paths where interception quietly doesn't happen, and the outcome is invisible: a normal-looking Codex TUI that simply never receives messages. The configured delivery status remains monitor, but it does not report whether the current Codex process was actually launched through the bridge. I hit two of these in one afternoon and each took real debugging to identify.

Trap 1 — symlink install breaks the shim's self-location, silent fallback

codex-shim.sh locates its helpers relative to $0:

SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
...
status="$("$SCRIPT_DIR/../../../delivery.sh" status codex "$project" 2>/dev/null || true)"

If a user installs the shim as a symlink — which is consistent with the header comment, "Install this as ~/.agents/bin/codex before the real Codex binary on PATH" — dirname "$0" resolves to the symlink's directory, the delivery.sh lookup points at a nonexistent path, is_monitor_project returns false, and the shim execs plain Codex with no warning.

ln -s ~/.agents/skills/agmsg/scripts/drivers/types/codex/codex-shim.sh \
  ~/.agents/bin/codex
export PATH="$HOME/.agents/bin:$PATH"

cd /path/to/a/project-configured-for-monitor-mode
codex
# Actual: plain Codex starts; codex-monitor.sh is not invoked.
# Expected: monitored Codex starts, or the invalid installation is reported.

By contrast, codex-shim-install.sh install creates a wrapper that sets AGMSG_CODEX_SHIM_SCRIPT_DIR and does not exhibit this failure.

Trap 2 — shell-function setup never engages for non-interactive launchers

When the generated function (#193) is installed only in an interactive-shell startup path, non-interactive launchers do not define it. For example, on systems whose login profile sources .bashrc and whose .bashrc returns early for non-interactive shells, bash -l -c 'codex --yolo' resolves the underlying Codex executable instead of the function. Termux shortcuts, desktop launchers, cron jobs, and agent spawn commands may encounter this depending on their shell and PATH configuration. Again with no signal.

Suggestions

1. codex-shim.sh: resolve $0 through symlinks (readlink -f / a cd -P loop) so a symlink install works like a copy, or refuse loudly when the relative delivery.sh path doesn't exist instead of treating it as "not a monitor project".
2. When an invoked shim detects monitor mode but cannot locate its helper scripts, print a one-line stderr warning before failing open to plain Codex. For cases where the shim is never invoked, add a setup/status diagnostic that verifies how codex resolves in interactive and non-interactive shells — this seems like a good agmsg doctor check (Add agmsg doctor and viewer/status dashboard #267): "delivery mode is monitor but the codex command on PATH / shell function does not route through the shim."