[Bug]: Hermes Desktop does not appear to use the same profile terminal backend / sandbox as CLI profile command

[amurteza]

Bug Description

I am seeing different terminal execution behavior between a Hermes CLI profile and the Hermes Desktop app.

I created a dedicated profile for read-only SwiftUI code review. The goal is for the agent to inspect local changes between the current branch and local develop, using read-only commands such as git status, git diff, rg, cat, etc. The agent should not be able to modify files, access remote repositories, or use the internet.

When I run the profile from the CLI, the environment looks correct. The agent runs inside a sandbox-like workspace, the project is available at /workspace/project, the project mount is read-only, write attempts fail, and network access to GitHub fails.

Example CLI diagnostics:

pwd: /workspace/project
INSIDE_DOCKER: yes
mount: /run/host_mark/Users on /workspace/project type fakeowner (ro,nosuid,nodev,relatime,fakeowner)
touch /workspace/project/__hermes_write_test.txt:
Read-only file system
curl https://github.com:
failed to resolve github.com
git status:
works correctly inside the repository

However, when I try to use the same workflow from Hermes Desktop, the terminal appears to run locally on my Mac instead of using the same sandbox/profile environment. It starts in my home directory, has internet access, does not see /workspace/project, and is not inside the Git repository.

Example Desktop diagnostics:

pwd: /Users/askomur.mac
hostname: mac-askomur2.local
INSIDE_DOCKER: no
cat /proc/1/cgroup:
No such file or directory
touch /workspace/project/__hermes_write_test.txt:
No such file or directory
curl https://github.com:
HTTP/2 200
git status:
fatal: not a git repository

This makes the Desktop app unsuitable for the same read-only code review workflow, because it does not appear to honor the same profile terminal backend, working directory, sandbox, read-only mount, or network restrictions that work from the CLI.

Expected behavior:

Hermes Desktop should either:

1. use the same profile configuration and terminal backend as the selected CLI profile, including the configured working directory, read-only project mount, and network restrictions; or
2. clearly expose separate Desktop-specific settings for selecting the profile, working directory, sandbox/terminal backend, read-only project access, and network behavior.

Actual behavior:

The CLI profile runs in a restricted /workspace/project environment, while Desktop appears to run a local macOS shell from /Users/askomur.mac with internet access and without the project repository mounted.

I am not sure whether this is expected behavior, missing Desktop configuration, or a bug. The difference is surprising because the same intended agent/profile workflow behaves safely in CLI but differently in Desktop.

Steps to Reproduce

1. Create a dedicated Hermes profile for local read-only code review.

hermes profile create code-review --no-skills --description "Read-only local code review profile"
code-review setup

2. Configure the profile for a restricted local review workflow. The local project path can be any Git repository.

Example intended setup:

Profile name: code-review
Project path: /Users//Developer/
Workspace path expected inside the agent: /workspace/project
Goal: read-only access to the local repository, no internet access, no remote repository access

3. Start the profile from the CLI.

code-review chat

4. In the CLI session, run these diagnostic commands:

pwd
hostname
test -f /.dockerenv && echo "INSIDE_DOCKER=yes" || echo "INSIDE_DOCKER=no"
cat /proc/1/cgroup || true
mount | grep /workspace/project || true
touch /workspace/project/__hermes_write_test.txt
echo write_exit_code=$?
ls -la /workspace/project/__hermes_write_test.txt 2>/dev/null || true
command -v curl || echo "CURL_MISSING"
curl -I https://github.com --max-time 5 --connect-timeout 3 2>&1
echo curl_exit_code=$?
git --no-pager status --short --branch

5. Observe that the CLI profile runs in the expected restricted environment. In my case, the CLI session shows /workspace/project, read-only project access, failed write attempts, failed network access, and a valid Git repository.
6. Open Hermes Desktop.
7. Try to use the same profile/workflow from Desktop, or open what appears to be the equivalent Desktop agent/session.
8. Run the same diagnostic commands in the Desktop session:

pwd
hostname
test -f /.dockerenv && echo "INSIDE_DOCKER=yes" || echo "INSIDE_DOCKER=no"
cat /proc/1/cgroup || true
mount | grep /workspace/project || true
touch /workspace/project/__hermes_write_test.txt
echo write_exit_code=$?
ls -la /workspace/project/__hermes_write_test.txt 2>/dev/null || true
command -v curl || echo "CURL_MISSING"
curl -I https://github.com --max-time 5 --connect-timeout 3 2>&1
echo curl_exit_code=$?
git --no-pager status --short --branch

9. Compare the results.

Expected Behavior

The Desktop session should use the same profile configuration, terminal backend, working directory, sandbox behavior, read-only project access, and network restrictions as the CLI profile.

Actual Behavior

The Desktop session appears to run in a different environment. In my case, it starts in the local macOS home directory, does not see /workspace/project, is not inside the Git repository, and has internet access.

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

No debug report. desktop work normally

Operating System

MacOS Tahoe 26.5.2

Python Version

No response

Hermes Version

0.18.2

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR