Skip to content

feat: Bases view scoping for agent tool calls #323

Description

@Leo310

Background

The Spaces feature (removed in #322) let users scope all agent tool calls to a named subset of the vault. This issue tracks rebuilding that capability using Obsidian Bases directly, without the Spaces wrapper.

Goal

Users reference a Bases view using standard Obsidian wikilink syntax — `[[Projects.base#Active]]` — directly in chat, the same way they would reference any other note or heading. The agent reads the view's filter, resolves the matching note paths, and uses that as the scope for its tool calls.

Design: agent-driven, not programmatic

Referencing `[[Projects.base#Active]]` in a message is a reference, not an instruction to silently restrict all subsequent tool calls. Intercepting it and setting implicit session state would be opaque — the user asking about something outside that Base would just get a worse answer with no explanation.

Instead:

  • Expose an optional `scope` parameter on the relevant tools (`search_notes`, `list_directory`, `read_content`, `manage_notes`, `get_all_tags`, `get_properties`), accepting a resolved set of paths derived from the view's filter.
  • Teach the agent about Bases views in the system prompt so it understands what `[[File.base#View]]` references mean and when applying a scope is appropriate.
  • Let the agent decide when to scope, pass it explicitly to tool calls, and tell the user what it's doing ("I'll search within your Active Projects view").

This keeps scoping transparent and flexible. The contrast with privacy filtering is intentional: privacy is a security boundary (silent, non-overridable). View scoping is a query concern — it belongs in the agent's reasoning, not in hidden session state.

Key implementation note

The `ViewFilter` tree and `SpaceMembership*` helpers in `src/lib/views.ts` are still present (retained from the Spaces removal). They were designed to evaluate "does file X belong to this filter" and can be reused here. The main work is reading filter definitions from `.base` files and wiring a `scope` parameter into the tools.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions