[FEATURE]: Enterprise setting to exempt statusLine from allowManagedHooksOnly / disableAllHooks

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Enterprise-managed settings that lock down hook execution also unintentionally disable the status line, because Claude Code currently gates the status line behind the same trust/hook controls used for arbitrary hooks.

Specifically, in our environment:

• allowManagedHooksOnly=true is set (org-wide, for legitimate security reasons - restricting arbitrary unmanaged hook scripts from running).
• We do not set disableAllHooks, but per the docs this setting has the same effect on the status line, so the same gap applies there too.

The result: the status line silently stops working for all users under these managed settings, even though the status line isn't a general-purpose hook in the security-sensitive sense - it's a read-only display mechanism, not something that executes arbitrary managed-vs-unmanaged trust decisions in the same way. There's currently no way to unlock just the status line without loosening the broader hook restriction that the enterprise setting is meant to enforce.

Relevant docs: https://code.claude.com/docs/en/statusline#troubleshooting

"The same trust and disableAllHooks gates that apply to statusLine apply here... If disableAllHooks is set to true in your settings, the status line is also disabled. Remove this setting or set it to false to re-enable."

Proposed Solution

Add a distinct enterprise-managed setting (e.g. allowStatusLineHook or similar) that lets admins re-enable the status line specifically, independent of allowManagedHooksOnly and disableAllHooks. This would let organizations keep tight restrictions on general hook execution while still allowing the status line - which only displays contextual info like git branch/worktree - to function.

Ideal behavior:

1. Admin sets the managed setting to explicitly allow the status line, without having to relax allowManagedHooksOnly or disableAllHooks org-wide.
2. If the new setting is unset, current behavior (status line disabled under those gates) is preserved - fully backward compatible.
3. Documentation updated to clarify the override and its scope (i.e., it only affects statusLine rendering, not hook execution generally).

Motivation:
The status line is a meaningful quality-of-life feature, and more importantly a safety aid - clearly surfacing the current git branch/worktree helps prevent accidental commits/changes in the wrong context.

Alternative Solutions

_No response_

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

_No response_

Additional Context

_No response_