Plugins, hooks modules and /goal wait until your organization's settings are read

What

If you belong to an organization, its settings can decide whether hooks (your own commands that run at set points) and plugins (add-ons) are allowed. Claude Code now tracks whether those organization settings have been read yet, and holds back features that depend on them until it knows:

• Command plugins and marketplaces: plugins that come from commands, and plugin marketplaces (places plugins are installed from), are held while the organization's settings are unanswered. The marketplace check reports organization_unanswered. Before, only disableCommandPluginSources and allowManagedHooksOnly in the policy were checked.
• /goal: it can't run yet, with the message that your organization's settings haven't been read so it isn't known whether hooks are allowed.
• Hooks modules: the check that decides whether hooks and hooks modules (mods) may load now takes an organization value, alongside builtinsOnly and personsHeld. The default is unasked.
• Reload: once the answer arrives, plugins are reloaded. A full plugin refresh (refreshActivePlugins) now first waits on this hold (organizationAsk.heldReresolve) when an answer is pending.
• Unreadable policy: if the policy cannot be read, the session now stops with 'Your organization's policy could not be read, so this session cannot run a turn.' instead of a generic message, and you are told installed mods are not running. The wait now ends as a limit, a dead end or a release.

Why

In managed or hosted sessions, plugin commands, mods and /goal stay off until the organization's policy is known, instead of running before it loads. This can change what is available right after startup, and an unreachable policy now gives a specific reason.