Full access ignores Claude's own settings that turn off bypass mode

[shivamhwp]

Claude Code lets a user or an admin turn off bypass mode: permissions.disableBypassPermissionsMode: "disable" in any Claude settings file, including managed policy. It can also turn off Auto mode with disableAutoMode. T3's Full access ignores both today.

What happens on main now, tested with a project .claude/settings.json that turns off bypass and Auto:

• T3 still asks Claude for bypassPermissions. Current Claude CLIs (2.1.289 here) no longer refuse to start, as [Bug]: Claude "full access" fails to start when bypassPermissions is disabled by policy #4927 reported. They quietly fall back to the next allowed mode.
• T3's canUseTool callback then approves every tool call itself, because the thread is in Full access. So touch created.txt runs with no prompt, even though the user's Claude settings say tools need approval.

So the session no longer breaks, but T3 overrides a policy the user or their admin set in Claude.

The question for maintainers: should Full access respect Claude's own locks? I'd say yes. When Claude's settings turn off bypass, Full access should use the strongest mode Claude still allows (Auto, or Default if Auto is off too). T3 should send tool approvals through its normal approval UI, and show one notice in the thread saying why. Full access stays unchanged for everyone without those settings.

PR with that behavior, plus before/after recordings: #15964

Related: #4927, and the closed #7246 by @matsvarn, which tried to make sessions start when the CLI used to fail.