SSH /goal still asks for command approval despite Full Access

Summary

In a Codex SSH remote session configured with Full Access, the /goal flow still asks for command approval while trying to fetch the active goal. This appears to ignore the session's access/approval setting.

Environment

• Host context: SSH remote project
• Permission mode shown to the user: Full Access
• Trigger: /goal / fetch current goal
• Exact Codex client/CLI versions: not captured yet

Expected behavior

A remote session set to Full Access should not require per-command approval for normal shell commands spawned by /goal. If /goal intentionally runs in a stricter approval context, the UI should make that policy mismatch explicit.

Actual behavior

Codex asks for command approval despite the session/workspace showing Full Access, which blocks or slows the /goal lookup on SSH-hosted work.

Steps to reproduce

1. Connect Codex to an SSH project.
2. Set or verify the session access mode as Full Access.
3. Run /goal or trigger fetching the current goal.
4. Observe command approval prompts for commands started by that flow.

Impact

This breaks the expectation that Full Access can run goal lookup and related automation without manual approvals, especially for remote maintenance sessions where the user deliberately selected full command access.

Notes

The likely issue is that /goal may be launched under a different approval context than the active SSH session. If that is intentional, the product should expose the policy difference; otherwise the /goal command should inherit the active session's approval policy.