feat: open useful USER_TYPE-gated features to all users (#644)

* feat: open useful USER_TYPE-gated features to all users

Remove 13 process.env.USER_TYPE === 'ant' gates that restricted useful
features to Anthropic employees. These features work without Anthropic
infrastructure and are now available to all open-build users.

Features opened:
- Agent nesting (sub-agents can spawn sub-agents)
- Effort 'max' persistence in settings
- Plan mode interview phase (controlled by feature flags)
- Sandbox disabled commands (via ~/.claude/feature-flags.json)
- All tips visible to all users (plan mode, feedback, shift-tab)

Simplified:
- Fullscreen defaults to off (use /config to enable)
- Explore agent always uses haiku model
- Plan mode tool uses conservative prompt for all users

Continues the USER_TYPE cleanup from #637 (dead code) and builds
on #639 (local feature flags).

* fix: address Copilot review comments — remove residual dead code

1. bridgeConfig.ts: ungate bridge override functions — return env vars
   directly instead of hardcoded undefined
2. bridgeMain.ts + initReplBridge.ts: ungate sessionIngressUrl — read
   CLAUDE_BRIDGE_SESSION_INGRESS_URL without USER_TYPE check
3. tools.ts: remove dead ConfigTool/TungstenTool imports, narrow
   eslint-disable scope, stub REPLTool/SuggestBackgroundPRTool to null
4. readOnlyValidation.ts: remove orphaned ANT_ONLY_COMMAND_ALLOWLIST
   and unused GH_READ_ONLY_COMMANDS import
5. insights.ts: remove entire remote collection plumbing (types,
   functions, options, display logic)
6. osc.ts: hardcode supportsTabStatus() to false (internal-only feature)
7. state.ts: simplify addSlowOperation/getSlowOperations to no-ops,
   remove dead constants

* fix: address Copilot review on PR #644

1. settings/types.ts: allow 'max' effort level for all users in Zod
   schema — was still gated behind USER_TYPE=ant, causing 'max' to be
   silently dropped on settings reload
2. shouldUseSandbox.ts: defensively normalize disabledCommands from
   feature flag config with Array.isArray() guards

* fix: address second round of Copilot review on PR #644

1. shouldUseSandbox.ts: validate top-level shape of disabledCommands
   before accessing properties (handles null/primitive from feature flag)
2. fullscreen.ts: update JSDoc to reflect removal of USER_TYPE default
3. osc.ts: update JSDoc — "Ant-only" → "Currently disabled"

src/tools/AgentTool/built-in/exploreAgent.ts

@@ -73,9 +73,8 @@ export const EXPLORE_AGENT: BuiltInAgentDefinition = {
   ],
   source: 'built-in',
   baseDir: 'built-in',
-  // Ants get inherit to use the main agent's model; external users get haiku for speed
-  // Note: For ants, getAgentModel() checks tengu_explore_agent GrowthBook flag at runtime
-  model: process.env.USER_TYPE === 'ant' ? 'inherit' : 'haiku',
+  // Use haiku for speed — explore is a fast read-only search agent
+  model: 'haiku',
   // Explore is a fast read-only search agent — it doesn't need commit/PR/lint
   // rules from CLAUDE.md. The main agent has full context and interprets results.
   omitClaudeMd: true,

src/tools/BashTool/readOnlyValidation.ts

@@ -15,7 +15,6 @@ import {
   DOCKER_READ_ONLY_COMMANDS,
   EXTERNAL_READONLY_COMMANDS,
   type FlagArgType,
-  GH_READ_ONLY_COMMANDS,
   GIT_READ_ONLY_COMMANDS,
   PYRIGHT_READ_ONLY_COMMANDS,
   RIPGREP_READ_ONLY_COMMANDS,
@@ -1136,68 +1135,6 @@ const COMMAND_ALLOWLIST: Record<string, CommandConfig> = {
   ...DOCKER_READ_ONLY_COMMANDS,
 }
 
-// gh commands are internal-only since they make network requests, which goes against
-// the read-only validation principle of no network access
-const ANT_ONLY_COMMAND_ALLOWLIST: Record<string, CommandConfig> = {
-  // All gh read-only commands from shared validation map
-  ...GH_READ_ONLY_COMMANDS,
-  // aki — internal knowledge-base search CLI.
-  // Network read-only (same policy as gh). --audit-csv omitted: writes to disk.
-  aki: {
-    safeFlags: {
-      '-h': 'none',
-      '--help': 'none',
-      '-k': 'none',
-      '--keyword': 'none',
-      '-s': 'none',
-      '--semantic': 'none',
-      '--no-adaptive': 'none',
-      '-n': 'number',
-      '--limit': 'number',
-      '-o': 'number',
-      '--offset': 'number',
-      '--source': 'string',
-      '--exclude-source': 'string',
-      '-a': 'string',
-      '--after': 'string',
-      '-b': 'string',
-      '--before': 'string',
-      '--collection': 'string',
-      '--drive': 'string',
-      '--folder': 'string',
-      '--descendants': 'none',
-      '-m': 'string',
-      '--meta': 'string',
-      '-t': 'string',
-      '--threshold': 'string',
-      '--kw-weight': 'string',
-      '--sem-weight': 'string',
-      '-j': 'none',
-      '--json': 'none',
-      '-c': 'none',
-      '--chunk': 'none',
-      '--preview': 'none',
-      '-d': 'none',
-      '--full-doc': 'none',
-      '-v': 'none',
-      '--verbose': 'none',
-      '--stats': 'none',
-      '-S': 'number',
-      '--summarize': 'number',
-      '--explain': 'none',
-      '--examine': 'string',
-      '--url': 'string',
-      '--multi-turn': 'number',
-      '--multi-turn-model': 'string',
-      '--multi-turn-context': 'string',
-      '--no-rerank': 'none',
-      '--audit': 'none',
-      '--local': 'none',
-      '--staging': 'none',
-    },
-  },
-}
-
 function getCommandAllowlist(): Record<string, CommandConfig> {
   let allowlist: Record<string, CommandConfig> = COMMAND_ALLOWLIST
   // On Windows, xargs can be used as a data-to-code bridge: if a file contains
@@ -1208,9 +1145,6 @@ function getCommandAllowlist(): Record<string, CommandConfig> {
     const { xargs: _, ...rest } = allowlist
     allowlist = rest
   }
-  if (process.env.USER_TYPE === 'ant') {
-    return { ...allowlist, ...ANT_ONLY_COMMAND_ALLOWLIST }
-  }
   return allowlist
 }
 

src/tools/BashTool/shouldUseSandbox.ts

@@ -19,34 +19,43 @@ type SandboxInput = {
 // It is not a security bug to be able to bypass excludedCommands — the sandbox permission
 // system (which prompts users) is the actual security control.
 function containsExcludedCommand(command: string): boolean {
-  // Check dynamic config for disabled commands and substrings (only for ants)
-  if (process.env.USER_TYPE === 'ant') {
-    const disabledCommands = getFeatureValue_CACHED_MAY_BE_STALE<{
-      commands: string[]
-      substrings: string[]
-    }>('tengu_sandbox_disabled_commands', { commands: [], substrings: [] })
+  // Check dynamic config for disabled commands and substrings
+  const raw = getFeatureValue_CACHED_MAY_BE_STALE<{
+    commands: string[]
+    substrings: string[]
+  }>('tengu_sandbox_disabled_commands', { commands: [], substrings: [] })
 
-    // Check if command contains any disabled substrings
-    for (const substring of disabledCommands.substrings) {
-      if (command.includes(substring)) {
+  const disabledCommands =
+    typeof raw === 'object' && raw !== null
+      ? raw
+      : { commands: [], substrings: [] }
+  const substrings = Array.isArray(disabledCommands.substrings)
+    ? disabledCommands.substrings
+    : []
+  const commands = Array.isArray(disabledCommands.commands)
+    ? disabledCommands.commands
+    : []
+
+  // Check if command contains any disabled substrings
+  for (const substring of substrings) {
+    if (command.includes(substring)) {
+      return true
+    }
+  }
+
+  // Check if command starts with any disabled commands
+  try {
+    const commandParts = splitCommand_DEPRECATED(command)
+    for (const part of commandParts) {
+      const baseCommand = part.trim().split(' ')[0]
+      if (baseCommand && commands.includes(baseCommand)) {
         return true
       }
     }
-
-    // Check if command starts with any disabled commands
-    try {
-      const commandParts = splitCommand_DEPRECATED(command)
-      for (const part of commandParts) {
-        const baseCommand = part.trim().split(' ')[0]
-        if (baseCommand && disabledCommands.commands.includes(baseCommand)) {
-          return true
-        }
-      }
-    } catch {
-      // If we can't parse the command (e.g., malformed bash syntax),
-      // treat it as not excluded to allow other validation checks to handle it
-      // This prevents crashes when rendering tool use messages
-    }
+  } catch {
+    // If we can't parse the command (e.g., malformed bash syntax),
+    // treat it as not excluded to allow other validation checks to handle it
+    // This prevents crashes when rendering tool use messages
   }
 
   // Check user-configured excluded commands from settings

src/tools/EnterPlanModeTool/prompt.ts

@@ -98,73 +98,6 @@ User: "What files handle routing?"
 `
 }
 
-function getEnterPlanModeToolPromptAnt(): string {
-  // When interview phase is enabled, omit the "What Happens" section —
-  // detailed workflow instructions arrive via the plan_mode attachment (messages.ts).
-  const whatHappens = isPlanModeInterviewPhaseEnabled()
-    ? ''
-    : WHAT_HAPPENS_SECTION
-
-  return `Use this tool when a task has genuine ambiguity about the right approach and getting user input before coding would prevent significant rework. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-Plan mode is valuable when the implementation approach is genuinely unclear. Use it when:
-
-1. **Significant Architectural Ambiguity**: Multiple reasonable approaches exist and the choice meaningfully affects the codebase
-   - Example: "Add caching to the API" - Redis vs in-memory vs file-based
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-
-2. **Unclear Requirements**: You need to explore and clarify before you can make progress
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Refactor this module" - need to understand what the target architecture should be
-
-3. **High-Impact Restructuring**: The task will significantly restructure existing code and getting buy-in first reduces risk
-   - Example: "Redesign the authentication system"
-   - Example: "Migrate from one state management approach to another"
-
-## When NOT to Use This Tool
-
-Skip plan mode when you can reasonably infer the right approach:
-- The task is straightforward even if it touches multiple files
-- The user's request is specific enough that the implementation path is clear
-- You're adding a feature with an obvious implementation pattern (e.g., adding a button, a new endpoint following existing conventions)
-- Bug fixes where the fix is clear once you understand the bug
-- Research/exploration tasks (use the Agent tool instead)
-- The user says something like "can we work on X" or "let's do X" — just get started
-
-When in doubt, prefer starting work and using ${ASK_USER_QUESTION_TOOL_NAME} for specific questions over entering a full planning phase.
-
-${whatHappens}## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Genuinely ambiguous: session vs JWT, where to store tokens, middleware structure
-
-User: "Redesign the data pipeline"
-- Major restructuring where the wrong approach wastes significant effort
-
-### BAD - Don't use EnterPlanMode:
-User: "Add a delete button to the user profile"
-- Implementation path is clear; just do it
-
-User: "Can we work on the search feature?"
-- User wants to get started, not plan
-
-User: "Update the error handling in the API"
-- Start working; ask specific questions if needed
-
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-`
-}
-
 export function getEnterPlanModeToolPrompt(): string {
-  return process.env.USER_TYPE === 'ant'
-    ? getEnterPlanModeToolPromptAnt()
-    : getEnterPlanModeToolPromptExternal()
+  return getEnterPlanModeToolPromptExternal()
 }