Skip to content

feat(zsh): Implement Temporary Agent Context for One-Off Commands #1900

@dariuszkowalski-com

Description

@dariuszkowalski-com

Description

Currently, when executing a prompt via :agent prompt in the ZSH plugin, the context switches to the specified agent and remains there, affecting subsequent commands. This leads to confusion, as any following prompts or custom commands are executed in the unintended agent context. The desired behavior is to allow temporary switching of agent context for one-off commands only, while maintaining the persistent context as before.

Current Behavior

  • After running :agent prompt, the plugin switches context to the specified agent and stays in that context.
  • Subsequent usages of : prompt or custom commands :custom-command continue to run in the new agent's context.
  • This causes subsequent operations to use the tools, system, and user prompts of the unintended agent.
  • Agent call as indistinguishable from commands: :forge ,:s looks the same. The command do not change a state of environment but agents do
  • After running :agent without prompt we get info about activation:
> $ :forge
⏺ [16:42:44] FORGE is now the active agent
  • After running :agent prompt there is no such message and user see only what agent is doing. It looks like commands (look at screenshot)

Proposed Changes

  • When executing :agent prompt, switch to the specified agent only for the execution of that prompt; do not persist the agent context.
  • After the one-off prompt execution, the context should revert to the previous (original) agent (e.g., 'forge').
  • Persistent context changes should only happen via explicit :agent command without arguments or with a
    context-switching flag.
  • :prompt and custom commands should always execute in the currently active (persistent) agent context unless
    temporarily overridden.

Illustrative Scenarios:

  1. Scenario A (Explicit Context Switch):

    • User is in 'forge' context.
    • Executes :agent to switch context.
    • Prompts and custom commands now use the new agent context.
  2. Scenario B (Temporary/One way Context):

    • User is in 'forge' context.
    • Executes :agent prompt (with a prompt argument).
    • The command runs in the specified agent context, but the persistent context remains as 'forge'.
    • Subsequent : prompt and custom commands use the original 'forge' context.

Benefits

  • Prevents accidental persistent context switches.
  • Makes agent context handling clear and predictable for commands intended as one-off/temporary.
  • Reduces confusion caused by agents’ different tools, system prompts and behaviors leaking into unintended contexts.
  • Ensures custom commands always execute in the expected agent context.

Implementation Notes

  • Requires internal tracking and restoration of previous agent context after one way commands.
  • UI/UX should clearly differentiate between persistent and temporary context switches.
  • Consider documenting this behavior for end-users in plugin/help documentation.

Screnshots

Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions