[Feature Request] Secure repository publishing with GitHub App authentication

[theshwal]

Context

OpenFox currently relies on whatever Git authentication is already available in its environment. The existing Commit & Push command asks the LLM to run Git commands directly, so branch publication depends on a personal SSH key, PAT, or preconfigured gh session.

This issue targets self-hosted OpenFox installations that need a non-personal, short-lived publishing identity without changing the maintainer-provided command or exposing credentials to the model.

Goal

Add a secure native publication path that can:

• create a commit with an explicitly configured author;
• push a branch using either existing Git credentials or a GitHub App installation token;
• optionally create a pull request after a successful push;
• keep all GitHub App secrets outside the LLM, generic shell environment, project workspace, repository files, logs, prompts, and diffs.

Preserve the existing command

The current Commit & Push command must remain unchanged.

Add a separate OpenFox workflow exposed as:

• name: Commit & Publish;
• slash command: /commit-publish.

This avoids changing or replacing the maintainer's existing behavior.

Proposed workflow

The workflow should combine deterministic native operations with LLM decisions:

1. Inspect changes
   • collect the current branch, modified files, staged files, repository remotes, and publication configuration;
   • perform no mutation.
2. Prepare commit
   • the LLM selects only the files belonging to the task;
   • the LLM proposes the commit message;
   • the LLM never receives publication credentials.
3. Commit changes
   • call a native commit_changes tool;
   • stage only the selected files;
   • apply the project-specific commit author;
   • return the commit SHA.
4. Publish branch
   • call a native publish_branch tool;
   • use the configured push remote and authentication mode;
   • return a structured result.
5. Pull request choice
   • after a successful push, present a workflow user step:
     • Create pull request;
     • Finish without pull request.
6. Create pull request
   • when selected, let the LLM prepare the title/body;
   • call a native create_pull_request tool;
   • use the configured pull-request target.
7. Report
   • show the commit SHA, pushed branch, source repository, target repository, and PR when created.

The workflow may use agent steps to call native tools. Adding a new workflow step type is not required for the MVP.

Repository resolution

An OpenFox project currently identifies a local repository through project.workdir.

Publication settings should therefore work as follows:

1. Detect Git remotes from the main repository at project.workdir.
2. Never infer the publication destination from a generated workspace clone, whose origin may point to the local source repository.
3. Store the selected remote names in the project settings:
   • pushRemote;
   • pullRequestRemote.
4. Resolve the current URL of those remotes from the main repository again at publication time.

Recommended defaults:

• push remote: origin;
• pull-request target: upstream when present, otherwise the push remote.

This supports both:

• a project where push and PR target are the same repository;
• a fork workflow where the branch is pushed to origin and the PR targets upstream.

The MVP should not include a repository browser, clone manager, or full .git/config editor.

UI / UX

Global settings

Add a generic section:

Repository Publishing > GitHub

Fields and actions:

• App ID;
• private-key file path;
• connection status;
• Test connection.

Do not expose or store:

• the private-key contents;
• JWTs;
• installation access tokens;
• a manually entered installation ID.

The installation should be resolved automatically for the repository being published.

Project settings

Add a directly visible project-scoped section:

<project name> Settings > Repository Publishing

It must not be hidden behind a global or unrelated “Advanced Settings” area.

Show:

• detected local project path;
• push repository selector, with remote name and resolved destination;
• pull-request target selector, with remote name and resolved destination;
• authentication mode:
  • existing Git credentials;
  • GitHub App;
• commit author name;
• commit author email;
• current readiness status;
• Verify setup action.

Example:

Repository Publishing

Push repository
origin — github.com/theshwal/openfox

Pull request target
upstream — github.com/co-l/openfox

Authentication
GitHub App

Commit author
theshwal <...@users.noreply.github.com>

Status
Ready

Project publication choices are stored per project. GitHub App secrets remain global and outside the project configuration.

Authentication architecture

Use a central publication layer with internal authentication providers:

• environment: preserve existing SSH/PAT/credential-helper behavior;
• github-app: add GitHub App authentication.

The generic Git push path should not depend directly on GitHub-specific concepts, but this issue only implements GitHub.com and GitHub App authentication. GitLab, Forgejo, Gitea, GitHub Enterprise Server, and other forges are out of scope.

MVP GitHub App constraints

• one GitHub App configured globally;
• GitHub.com only;
• private key supplied only by file path outside project workspaces;
• App installation resolved automatically for the target repository;
• installation token restricted to the repository and required permissions when supported;
• token cached in memory only and renewed on demand shortly before expiry;
• no background refresh service;
• no multi-App management UI.

Security boundary

The LLM may decide what to commit and how to describe the commit or PR. It must not decide how credentials are constructed or injected.

Required guarantees:

• the private key and generated tokens are never included in prompts or tool results;
• GitHub App variables are never added to the generic shell environment used by the agent;
• only the native publication process receives temporary credentials;
• credentials are scoped to the publication process and removed afterwards;
• no credential is written to SQLite, .openfox/, the project workspace, a generated workspace, .git/config, or a remote URL;
• stdout and stderr are redacted before logging or returning results to the LLM;
• repository remotes are not persistently rewritten to include credentials.

Failure behavior

Commit, push, and PR creation must remain separate operations.

• If the commit succeeds and the push fails, keep the local commit.
• Do not automatically perform a rebase in the MVP.
• Return an actionable structured error such as remote ahead, authentication unavailable, App not installed, repository inaccessible, insufficient permission, invalid remote, protected branch, or unsupported host.
• Allow publish_branch to be retried without recreating the commit.
• If PR creation fails after a successful push, preserve the pushed branch and allow PR creation to be retried independently.
• Avoid silently creating duplicate pull requests when an existing PR for the same source/target can be identified.

Acceptance criteria

• The existing Commit & Push command is unchanged.
• A new Commit & Publish workflow is available through /commit-publish.
• The workflow uses native commit_changes, publish_branch, and create_pull_request capabilities.
• The LLM selects files and prepares human-readable commit/PR text but never receives publication credentials.
• Repository remotes are discovered from the main project repository, never from workspace clones.
• Push and PR-target remote names are configurable and persisted per project.
• Remote URLs are resolved and validated again at publication time.
• Existing SSH/PAT authentication continues to work through the same publication layer.
• GitHub App authentication can be enabled per project.
• A single global GitHub App can authenticate publication without a manually configured installation ID.
• Installation access is verified against the push repository before publication.
• GitHub App tokens are short-lived, repository-scoped where possible, memory-only, and renewed on demand.
• Commit author name/email are project-configurable and independent from the publishing identity.
• A successful push can finish without a PR or continue to PR creation through a workflow user choice.
• Push failure does not remove or recreate the local commit.
• PR-creation failure does not undo the successful push.
• Secrets are absent from logs, prompts, tool results, diffs, project files, database records, Git config, and remote URLs.
• Project Settings contains a directly visible Repository Publishing section.
• Global Settings contains Repository Publishing > GitHub for App ID, private-key path, connection test, and status.
• Setup verification returns clear, actionable errors.
• Documentation covers App creation, minimum permissions, key placement, project setup, same-repository publication, and fork-to-upstream publication.

Required validation scenarios

1. Existing SSH/PAT publication remains functional.
2. GitHub App push and PR creation within the same repository.
3. Fork flow:
   • push branch to the configured fork remote;
   • create a PR against the configured upstream remote;
   • document the exact GitHub App installation and permission requirements observed in the real test.
4. App not installed on the push repository.
5. App installed but missing Contents: write.
6. PR target inaccessible or missing the required pull-request permission.
7. Push rejected because the remote branch advanced.
8. Secret-bearing error/output is redacted.
9. Workspace origin points locally, while publication still uses the project-configured remote.

Out of scope

• modifying or replacing the existing Commit & Push command;
• automatic commit signing;
• automatic rebase or conflict resolution;
• multiple GitHub Apps;
• OAuth user login;
• webhook processing;
• automatic GitHub App installation;
• internal secret-vault management;
• storing private keys or tokens in project configuration;
• a full remote editor or repository browser;
• support for non-GitHub forges in this issue;
• a new workflow step type dedicated to native tools.