Slack CLI fails in the Agent sandbox when it cannot write $HOME/.slack/logs, with an error that looks unrelated to Slack

[liuchao-001]

What happens

An Agent Turn that tries to use the official Slack CLI fails on its first, correct invocation because the CLI cannot write its debug log under $HOME, which the Agent sandbox denies. The error names a log file, so it reads as nothing to do with Slack, with Slack credentials, or with the sandbox.

Observed during independent live QA on a real Slack workspace. The Agent sourced the projected per-Turn credential file and ran the documented command:

source "$OPENTAG_PROVIDER_ENV_FILE" && slack api chat.postMessage channel=C… text=…

and got, with no API call attempted:

2026/08/22 18:59:34 open /Users/super/.slack/logs/slack-debug-20260823.log: operation not permitted
2026/08/22 18:59:34 open /Users/super/.slack/logs/slack-debug-20260823.log: operation not permitted
   … repeated ~8x, exit non-zero, no request sent

The Turn only succeeded because the model improvised a workaround on its own — it took four attempts:

1. slack api --help (worked; the binary is fine)
2. slack api chat.postMessage … → the permission spam above
3. … --config-dir /private/tmp/opentag-slack-config → stat: no such file or directory
4. mkdir -p /private/tmp/opentag-slack-config then … --config-dir … → {"ok":true,"channel":"C…","ts":"…"}

Why it matters

• The failure looks unrelated to Slack. The message is about a log file under $HOME/.slack/logs, so diagnosis starts in the wrong place — sandbox policy, credentials, and the CLI binary all look fine. This is the expensive part.
• It depends on the model being resourceful. Inventing --config-dir and pre-creating the directory is not obvious. A provider that follows the documented command and stops would simply fail the Turn, and the Agent would appear silently broken in the channel.
• Readiness does not catch it. The IM CLI readiness probe runs slack version / slack api --help from the daemon process, which is not sandboxed, so it reports ready while the sandboxed Agent invocation still fails. providerCliReadiness: ready is therefore not evidence that the Agent can use the CLI — the probe and the real call run in different environments.

Suggested direction

Project a writable Slack config directory per Turn rather than relying on the Agent to invent one:

1. Create a per-Turn writable directory and point the CLI at it through the credential environment file alongside SLACK_BOT_TOKEN, so the documented command works unmodified. Confirm against the installed CLI whether a config-dir environment variable is honoured; if not, the managed prompt rule must pass --config-dir explicitly.
2. Add the --config-dir rule to the managed Slack CLI guidance as the fallback.
3. Consider making the readiness probe representative of the sandbox the Agent actually runs in, or stop treating it as evidence that Agent-side invocation works.

Notes

Found while running independent live QA of the Slack binding flow against a real workspace (related: #99, and the binding flow in #113). The outbound path itself is sound — once the config directory was writable, the Agent posted successfully to the real channel using only the projected SLACK_BOT_TOKEN with no slack login. This issue is purely about the sandbox/config-dir precondition.