daemon.cjs · part 341

60 text occurrences from desktop/Cursor.app/Contents/Resources/app/extensions/cursor-agent-host/dist/agent-host-daemon/dist/bin/daemon.cjs, part 341. Every entry preserves the shipped literal and its saved verdict or selection reason.

File contents and all parts · All files

use strict

use strict

Find snippets of code from the codebase most relevant to the search query.
This is a semantic search tool, so the query should ask for something semantically matching what is needed.
Ask a complete question about what you want to understand. Ask as if talking to a colleague: 'How does X work?', 'What happens when Y?', 'Where is Z handled?
If it makes sense to only search in particular directories, please specify them in the target_directories field (single directory only, no glob patterns).

One sentence explanation as to why this tool is being used, and how it contributes to the goal.

A complete question about what you want to understand. Ask as if talking to a colleague: 'How does X work?', 'What happens when Y?', 'Where is Z handled?'

Prefix directory paths to limit search scope (single directory only, no glob patterns)

If true, only search pull requests and return no code results.

The number of results to return. Must be between 1 and ${topK}.

The number of results to return. Defaults to ${topK}. Do not specify a value larger than ${topK}.

`${semanticSearchName}`: semantic search that finds code by meaning, not exact text

### When to Use This Tool

Use `${semanticSearchName}` when you need to:
- Explore unfamiliar codebases
- Ask "how / where / what" questions to understand behavior
- Find code by meaning rather than exact text

### When NOT to Use

Skip `${semanticSearchName}` for:
1. Exact text matches (use `${grepName}`)
2. Reading known files (use `${readName}`)
3. Simple symbol lookups (use `${grepName}`)
4. Find file by name (use `${globName}`)

### Examples

<example>
  Query: "Where is interface MyInterface implemented in the frontend?"
<reasoning>
  Good: Complete question asking about implementation location with specific context (frontend).
</reasoning>
</example>

<example>
  Query: "Where do we encrypt user passwords before saving?"
<reasoning>
  Good: Clear question about a specific process with context about when it happens.
</reasoning>
</example>

<example>
  Query: "MyInterface frontend"
<reasoning>
  BAD: Too vague; use a specific question instead. This would be better as "Where is MyInterface used in the frontend?"
</reasoning>
</example>

<example>
  Query: "AuthService"
<reasoning>
  BAD: Single word searches should use `${grepName}` for exact text matching instead.
</reasoning>
</example>

<example>
  Query: "What is AuthService? How does AuthService work?"
<reasoning>
  BAD: Combines two separate queries. A single semantic search is not good at looking for multiple things in parallel. Split into separate parallel searches: like "What is AuthService?" and "How does AuthService work?"
</reasoning>
</example>

### Target Directories

- Provide ONE directory or file path; [] searches the whole repo. No globs or wildcards.
  Good:
  - ["backend/api/"]   - focus directory
  - ["src/components/Button.tsx"] - single file
  - [] - search everywhere when unsure
  BAD:
  - ["frontend/", "backend/"] - multiple paths
  - ["src/**/utils/**"] - globs
  - ["*.ts"] or ["**/*"] - wildcard paths

### Search Strategy

1. Start with exploratory queries - semantic search is powerful and often finds relevant context in one go. Begin broad with [] if you're not sure where relevant code is.
2. Review results; if a directory or file stands out, rerun with that as the target.
3. Break large questions into smaller ones (e.g. auth roles vs session storage).
4. For big files (>1K lines) run `${semanticSearchName}`, or `${grepName}` if you know the exact symbols you're looking for, scoped to that file instead of reading the entire file.

<example>
  Step 1: { "query": "How does user authentication work?", "target_directories": [], "explanation": "Find auth flow" }
  Step 2: Suppose results point to backend/auth/ → rerun:
          { "query": "Where are user roles checked?", "target_directories": ["backend/auth/"], "explanation": "Find role logic" }
<reasoning>
  Good strategy: Start broad to understand overall system, then narrow down to specific areas based on initial results.
</reasoning>
</example>

<example>
  Query: "How are websocket connections handled?"
  Target: ["backend/services/realtime.ts"]
<reasoning>
  Good: We know the answer is in this specific file, but the file is too large to read entirely, so we use semantic search to find the relevant parts.
</reasoning>
</example>

### Usage
- When full chunk contents are provided, avoid re-reading the exact same chunk contents using the ${readName} tool.
- Sometimes, just the chunk signatures and not the full chunks will be shown. Chunk signatures are usually Class or Function signatures that chunks are contained in. Use the ${readName} or ${grepName} tools to explore these chunks or files if you think they might be relevant.
- When reading chunks that weren't provided as full chunks (e.g. only as line ranges or signatures), you'll sometimes want to expand the chunk ranges to include the start of the file to see imports, expand the range to include lines from the signature, or expand the range to read multiple chunks from a file at once.

use strict

A complete question about what you want to understand. Ask as if talking to a colleague: 'How does X work?', 'What happens when Y?', 'Where is Z handled?'

Prefix directory paths to limit search scope (single directory only, no glob patterns)

The number of results to return. Must be between 1 and ${topK}.

The number of results to return. Defaults to ${topK}. Do not specify a value larger than ${topK}.

Codebase search is unavailable for this conversation because the codebase index could not be found. Do not retry ${searchName}. Use ${grepName}, ${globName}, and ${readName} instead.

Unhandled version: ${_exhaustive}

`SemanticSearch`: semantic search that finds code by meaning, not exact text

Unhandled version: ${_exhaustive}

The semantic search results are empty. Consider using a different search query or using grep search instead to find relevant results.

use strict

Object expected.

Symbol.asyncDispose is not defined.

Symbol.dispose is not defined.

Object not disposable.

An error was suppressed during disposal.

No codebase index found. Use other search tools.

Index invalid. Use other search tools.

${meta.toolCallId}-${(0, import_node_crypto34.createHash)("sha256").update(decryptedPath).digest("hex").substring(0, 8)}

Error: ${result.value.errorMessage}

Unknown error

use strict

tmux -f /exec-daemon/tmux.portal.conf

On this self-hosted machine, invoke tmux without `-f`. If `tmux` is not installed (`command -v tmux` prints nothing), run long-lived commands in the background with this tool instead.

On the VM, invoke tmux with `-f /exec-daemon/tmux.portal.conf`. If that config path is unavailable, fall back to the same command without `-f`.

SESSION_NAME="${sessionName}"; ${tmux} has-session -t "=$SESSION_NAME" 2>/dev/null || ${tmux} new-session -d -s "$SESSION_NAME" -c "$PWD" -- "${SHELL:-zsh}" -l

Use a descriptive tmux session name for the task or command instead of a single global shared name. Prefer short kebab-case names such as `vite-dev-server`, `backend-tests`, or `db-migration`.

There is one canonical shared tmux session for most recurring shell work — `${sharedSessionName}`. Start or reuse that session before ordinary setup work, then use it for every install, build, migration, version check, and verification command. Only create a separate descriptively-named session (short kebab-case, e.g. `vite-dev-server`, `backend-tests`, `postgres`) for long-running side processes that must keep running after a single command finishes. Do NOT invent a new per-task session name for ordinary shell work — route it through `${sharedSessionName}`.

<tmux-backed-shell-sessions>
- tmux is the required mechanism for shell work that may outlive a single command. If you need an interactive shell, any background command (such as starting dev servers), a long-running process, follow-up input, later inspection, or a shared session that you or the user may reconnect to later, you MUST use tmux. Do NOT launch those workflows as one-shot background processes. If you are planning to set block_until_ms to 0, you should ALWAYS back this session with tmux.
- ${tmuxConfigGuidance(selfHostedMachine)}
- ${namingGuidance}
- Start or reuse the appropriate session by running `${getTmuxBootstrapCommand({ sharedSessionName, selfHostedMachine })}`.
- Before creating a new session, list existing sessions with `${tmux} ls` and reuse an existing one when appropriate.
- To inspect or continue work in an existing session, attach with `${tmux} attach-session -t "$SESSION_NAME"`.
- To send input to a session without attaching, run `${tmux} send-keys -t "$SESSION_NAME:0.0" 'your command here' C-m`.
</tmux-backed-shell-sessions>

tmux is the required mechanism for shell work that may outlive a single command. If you need an interactive shell, any background command (such as starting dev servers), a long-running process, follow-up input, later inspection, or a shared session that you or the user may reconnect to later, you MUST use tmux. Do NOT launch those workflows as one-shot background processes. If you are planning to set block_until_ms to 0, you should ALWAYS back this session with tmux.

There is one canonical shared tmux session for most recurring shell work — `

`. Start or reuse that session before ordinary setup work, then use it for every install, build, migration, version check, and verification command. Only create a separate descriptively-named session (short kebab-case, e.g. `vite-dev-server`, `backend-tests`, `postgres`) for long-running side processes that must keep running after a single command finishes. Do NOT invent a new per-task session name for ordinary shell work — route it through `

Use a descriptive tmux session name for the task or command instead of a single global shared name. Prefer short kebab-case names such as `vite-dev-server`, `backend-tests`, or `db-migration`.

Start or reuse the appropriate session by running

`${getTmuxBootstrapCommand({ sharedSessionName, selfHostedMachine })}`

Before creating a new session, list existing sessions with 

`${tmux} ls`

 and reuse an existing one when appropriate.

To inspect or continue work in an existing session, attach with

`${tmux} attach-session -t "$SESSION_NAME"`

To send input to a session without attaching, run

`${tmux} send-keys -t "$SESSION_NAME:0.0" 'your command here' C-m`

use strict

Optional list of permissions to request if the command needs them (full_network).

Optional list of permissions to request if the command needs them (full_network, all).

Optional list of permissions to request if the command needs them (full_network, all).

use strict

The sandbox includes network access for common package managers and version control providers (e.g. npm, pypi, crates.io, Maven Central, GitHub, etc.). Standard operations like package installs and fetching dependencies will work without requesting additional permissions.

Additionally, the

 sandbox includes network access for the following domains: