Skip to content

feat(ssh): open the local SSH window from Atenea chats #149

Description

@Tutitoos

Parent tracking issue: #141. Phase 9 of 11.

Objective

Expose the local window opener to an Atenea-enabled conversation without mislabeling the launch as read-only.

Scope

Add a typed side-effect-aware opener capability/command and discoverable chat instruction for atenea-ssh. Existing atenea.command is a closed read-only contract; do not silently add a window-launch mutation under its existing read-only annotations. Reuse the same OS-user-bound Wails app activation and authenticated controller IPC as the Terminal path and the existing policy/effect checks.

Document how Codex/ChatGPT clients discover and invoke the command; typing a word in an unconfigured chat is not an automatic hook. It opens only on the actual controller host. Return distinct statuses for launch_requested, app_ready and window-visible/focus evidence where observable, headless/unavailable/denied and wrong-host. An OS process-launch or app-activation acknowledgment does not prove the window rendered. Do not expose bootstrap tokens, passwords, SSH config secrets or prompt history to the chat opener.

Repeated invocation reuses the controller without SSH dispatch. Test platform IPC according to #148 and retain local-user identity; a host label supplied by a remote chat is not authentication.

Test repeated activation in the correct logged-in graphical session, including simultaneous Terminal/chat calls. OS focus-stealing rules can prevent foreground activation: app_ready must not be reported as focused. The opener accepts no prompt, arbitrary URL/command or credentials and cannot dispatch SSH work. Publish separate evidence for each configured Codex/ChatGPT integration and each controller OS; an unconfigured or cloud-only client gets an explicit unavailable result.

Acceptance criteria

  • Terminal and an actual configured local chat reach the same authenticated controller.
  • Tool effect metadata and policy reflect a UI launch; existing read-only command behavior stays tested.
  • Misrouted/headless/unsupported clients return truthful status; process launch is not reported as rendering.
  • Repeated opens do not spawn duplicate controllers or connect to an SSH host.
  • Client installation/discovery instructions and at least one real local chat invocation are verified.

Validation and evidence level

Focused MCP/policy/CLI tests, provider-client discovery checks and local visible rendering. Verify relevant OS IPC separately.

Dependencies and risks

Depends on #148.

Out of scope

Automatic SSH tasks from the opener, arbitrary CLI passthrough or claimed support for an unconfigured cloud chat.

Delivery boundary

Parent #141 defines the shared product contract. This issue owns one reviewable change and its own validation; do not close the parent from its PR. Keep source implementation, automated checks, installation and observed client behavior distinct. No secrets, real prompts, account identifiers or unredacted device logs belong in GitHub evidence.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions