* perf(ssh): reuse one proxy connection for system SSH on Windows
Windows OpenSSH cannot multiplex (ControlMaster fails with "getsockname
failed: Not a socket"), so every system-SSH exec for a ProxyCommand or
ProxyJump target re-ran the proxy handshake. Hold one `ssh -N -L` through
the real proxy per session and dial later execs over 127.0.0.1 with
HostName/Port/ProxyCommand=none/ProxyJump=none/HostKeyAlias overrides.
The route starts after connect, is proven with a login before use, falls
back to per-command proxying on any failure, honors
systemSshConnectionReuse: false, and is torn down with its proxy child.
Rebased from #31731 (commits b1cdd46, 3835c2d, 6268f2f) onto current main,
including the pending-route cancellation fix from b301b6a.
Co-authored-by: Neil <neil@stably.ai>
* refactor(ssh): stop the loopback forward through process-host's tree kill
Reuse signalProcessTree instead of a hand-rolled taskkill-then-kill
fallback: it already joins an in-flight tree kill, refuses a reaped PID,
and falls back to killing the root, so the route keeps no parallel copy
of that logic.
* fix(ssh): harden the Windows loopback route against review findings
- Manual targets: take the forward's sshd port and the HostKeyAlias from
the stored endpoint; `ssh -G` ran on the label and named another host.
- Hold the forward with ServerAlive probes so a silently dead proxy ends
it and commands fall back instead of stalling on 127.0.0.1.
- Never route forwards: their argv must stay stable for orphan recovery,
and the route's own forward must take the real proxy.
- Upload sessions read the route per file, so an exited route's port is
not dialled after it closes.
- Skip the route for security-key identities, whose forward and probe
logins would each ask for an unprompted touch.
* fix(ssh): keep the loopback route for manual targets no Host block claims
The unclaimed-alias endpoint rewrite only applies to config-backed targets,
so manual targets with a configHost no block names stay eligible.
* fix(ssh): keep the held loopback forward non-interactive
The forward is an optional background login; with BatchMode=no a password or
passphrase login raised an extra prompt right after connect, which the
non-interactive probe then discarded anyway.
* fix(ssh): admit the loopback route only when it changes nothing but the route
Overriding HostName to 127.0.0.1 changes which ssh_config blocks match, so a
`Match host <real host>` block could silently switch the remote User (or
identities, certificates, known-hosts files) for every routed command. Run
`ssh -G` with and without the route options and refuse the route on any
difference outside HostName/Port/HostKeyAlias/ProxyCommand/ProxyJump.
Also ask the agent with `ssh-add -L` and refuse the route when it may hold a
security key, so the background forward and probe never request a touch.
Both checks run through process-host and fail closed.
* feat(ssh): make Windows proxy connection reuse an opt-in per-target setting
The loopback route rewrites HostName, which ssh_config can key settings on,
so it no longer turns on by itself: a new optional systemSshProxyConnectionReuse
field (default off, Windows only) enables it from the SSH host's Advanced
settings. Old clients and servers ignore or omit the field.
Admission stays as the safety net and now:
- takes the forward's sshd port and HostKeyAlias from the direct `ssh -G`,
so a manual host's own Host block cannot send the route to another sshd;
- refuses any non-routing value with a `%` token, which `ssh -G` can leave
unexpanded while a routed login expands `%h` to 127.0.0.1;
- checks the security-key and agent identities of every ProxyJump hop;
- asserts the routed config really dials 127.0.0.1 with no proxy left.
* fix(ssh): offer proxy reuse only for hosts this desktop dials, refuse ${VAR} paths
- The switch now appears only for this desktop's own SSH hosts. A paired
server's add-host dialog never shows or sends it, so an older server's
strict schema is never handed the new field, and a client's platform no
longer decides a server's setting.
- Admission also refuses `${VAR}` references, which `ssh -G` prints
unexpanded while a login expands them.
- Advanced no longer auto-opens just for the opt-in.
---------
Co-authored-by: Bingxin Xu <xubingxin.xbx@gmail.com>
* fix(mobile): preserve agent icons across stacked routes and tab updates
Closes#31939
* fix(renderer): address review feedback on mobile agent icon stability
* fix(renderer): fall back to customTitle when saved leafTitle is blank
* Keep mobile agent icons painted across retained routes
Use instance-specific OMP gradients and preserve bundled icon fallback during web image reload failures. Add a real mobile-web route-retention pixel regression.
Adapted from zhangxaochen’s scoped rendering fixes in #31948; unproven session equality and title changes are excluded.
Co-authored-by: zhangxaochen <zhangxaochen@163.com>
---------
Co-authored-by: Neil <neil@stably.ai>
* test: strengthen hook, build, and mobile lifecycle coverage
* fix: use relocated Jira types in issue user field
---------
Co-authored-by: OrcaWin <293788423+OrcaWin@users.noreply.github.com>
* feat(agents): store each agent's permission itself instead of typing flags into Arguments
Terminals and new chats read one stored choice per agent (Use the agent's own
settings, Ask for approval, Accept edits, Approve for me, Full access). Orca adds
the flag at launch; Arguments hold only the user's own text. A one-time move
lifts Orca's flags out of saved Arguments. Older clients still see and write
the flag as part of Arguments; the host translates.
* fix(agents): say the all-agents switch resets agents set separately; keep primitives unstyled
* test(agents): the one-time move returns every launch-profile field
* Fix permission carrier ownership and surface-specific defaults
* Preserve uncertain permission operands and name the option inventory
* Check env entries without indexing typed agent maps
* Combine Chat permission capability imports
* Use folder execution-host platform for permission environment
* Preserve launch map replacement and acknowledge permission saves
* Keep permission feedback fallbacks statically discoverable
* Provide preload platform to Agents settings render tests
* Preserve Gemini approval arguments under Full access
* fix(settings): retain complete environment edits through save outcomes
* fix(settings): narrow local failure scope and preserve host messages
* fix(settings): retire argument drafts after acknowledged saves
* fix(settings): keep Goose environment editable after reset
* fix(settings): show resolved arguments for legacy hosts
* Preserve pending environment resets and bound launch settings work
* Keep optional settings fallback in repository metadata reads
* Read repository visibility defaults through the raw settings fixtures
* Prepare whole Environment edits and retire unchanged drafts
* Keep Environment settings transitions in an acyclic module
* Update raw settings reader test fixtures
* Place test fixture safety notes on assertion starts
* test: pin permission settings work and recovery contracts
* test: type permission settings work fixtures
* test: cover migrated permission inputs and captured CLI grammar
* test: preserve typed permissions in WSL Claude restarts
* fix(orcad): add --reclaim-stale-lock for a lock no start may judge
On a Linux host with no machine id whose ~/.orca is on a network or FUSE
home, a lock left by the host's own previous boot names a PID that is
evidence only on the machine that issued it, so every start after a
reboot refused it, and the only way out was deleting orcad.lock by hand.
Starts still refuse it: losing contact is not proof of exit, and a home
other machines may share must never be taken over automatically. Now:
- `orca serve --reclaim-stale-lock` (and `orcad --reclaim-stale-lock`)
checks that the lock was written on this host, in an earlier boot, at
least 2 minutes ago, and that nothing answers at its holder's
endpoints. It prints the pid, host, boot and age and warns about other
machines sharing the home, and clears the lock only with --yes,
through the normal race-safe reclaim of that exact record.
- Lock records now name their host, as evidence for that command.
- The refusal has its own code, orcad_instance_lock_holder_unverifiable,
names the command, and exits 3, so `orca serve --supervise` waits on it
instead of giving up, and the desktop refuses on it like a held lock.
- orcad advertises orcad.stale-lock-reclaim.v1 so a client can offer
the command on hosts that have it.
Fixes#32177
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* fix(orcad): let --reclaim-stale-lock clear a reclaimer cut short by the reboot, and probe IPv6
A reclaimer from the same earlier boot on this host that the reboot cut
short left a recovery owner the command could never judge, so --yes
always failed. The confirmation now covers such an owner too, and only
one from this host's earlier boot. An IPv6 WebSocket endpoint is probed
by its bare address.
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* fix(cli): ship the stale-lock reclaim module with packaged builds, and refuse an unreachable lock
The CLI loads main modules from out/main after the main build replaces
it, so the reclaim module becomes a stable plain-Node entry and is
unpacked from the asar. A lock that cannot be stat'ed for any reason other
than absence (a permission error, say) is now a refusal, not "nothing to
reclaim".
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* fix(orcad): make --reclaim-stale-lock name the real data root and report a status
- The refusal prints a runnable command for the data root it refused:
an orcad names its own runtime and entry plus `--data-root <dir>`,
since managed hosts have neither `orca` nor `orcad` on PATH and their
data root is not the default. The hint is Linux-only.
- Both entry points take `--data-root` and `--json` and report one of
none, eligible, refused or reclaimed, each with its own exit code
(4, 2, 1, 0), so a missing lock never reads as a recovery.
- The evidence says nothing answers on this machine, and that the host
name and boot checks cannot rule out another machine with the same
name; --yes stays the gate.
- wss endpoints default to port 443, a same-boot branch that could never
run is gone, and the supervisor's standby line points at the command.
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* fix(orcad): point the eligible message at the same command plus --yes
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* fix(orcad): refuse an empty --data-root, and name the right program in reclaim hints
- `--data-root` with no usable value (a trailing flag, an empty or blank
string) prints usage and exits 1 on both entry points, never falling
back to the default profile.
- A refusal raised while the reclaim command itself runs names
`orca serve --reclaim-stale-lock`, not the binary the CLI runs under;
an orcad still names its own runtime and entry.
- The supervisor's standby hint includes this profile's --data-root.
- The unreadable-lock test is skipped when running as root.
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* test(cli): reuse the existing client stub for the --data-root refusal test
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
---------
Co-authored-by: Jesse Sanford <108698+jessesanford@users.noreply.github.com>
* feat(acp): ACP agents can declare a managed runtime installed on first chat start
An ACP launch spec may name a pinned runtime Orca installs under its locked
data folder. The stock lookup searches it last (Command, PATH, install
directories, managed folder); a start whose lookup missed installs it under
the acquisition's signal, then resolves the launch again. A Command setting,
restart-recovery reads and catalog probes never install.
The pinned-runtime materializer can now publish a verified multi-member
folder: extract once into staging, check each member's sha256, rename into
place, with a per-asset download size limit. Node's runtime path is unchanged.
* Fix ACP managed runtime lookup precedence
* feat(acp): ACP agents can run with a private per-process temp folder
* feat(acp): old managed runtime versions are removed at host start
Once per host start, the ACP registration removes every version beside an
agent's current managed runtime folder, and staging left by an earlier
process. One host owns the data root and ACP servers are never reattached
across host runs, so nothing runs from them. This process's own staging is
kept (a publish may be in flight). Best effort: a failure is logged and never
holds up a launch.
* feat(acp): a sign-in prompt on an ACP agent's stderr ends the start or turn signed out
An agent that waits for a browser sign-in prints a link on stderr and blocks for
minutes. A launch spec can now name that line (signInPrompt); the connection then
closes with a typed sign-in failure through the existing process owner, so a start
reads notSignedIn and a running turn fails signed out instead of settling unknown.
The matched line, which carries the sign-in URL, never enters the retained stderr
tail, errors or diagnostics.
* Prevent sign-in URLs leaking from long stderr lines
* feat(acp): an agent can enforce the permission mode itself through a session config option
An optional launch-spec field names the session config option and its ask/full values. Every new or
reopened session gets the value for the chat's full-access posture before it is exposed, and a refusal
fails the start. With the field present Orca no longer answers permission requests for the person.
No agent sets it yet.
* fix(acp): reject unconfirmed permission mode during acquisition
* feat(acp): an agent enforcing the permission mode itself runs the chat's own mode
The launch spec maps each chat permission mode to its session option value; a start sets the
value for the mode the host launches with (ask when it names none), replacing the global Agent
Permissions full-access read. A mid-chat change takes effect through the host's existing restart
of a child launched with another mode before the next send.
* Keep ACP session acquisition within the line limit
* feat(acp): open Antigravity in the Chat UI over its ACP server
With the experimental chat setting on, Antigravity chats run Google's
Antigravity ACP server, which Orca installs on the first chat start: a
pinned 1.3.0 release whose archive and both executables are verified by
hash (macOS arm64/x64, Linux x64/arm64).
Each host keeps one private sign-in folder for these chats under Orca's
data folder, made owner-only before every start; the server keeps its
sign-in there as a file. A chat signs in with the server's Google method
through the existing auth-required retry; with no saved sign-in the
server's sign-in prompt ends the chat signed out. The Agent Permissions
setting maps to the server's own mode, and a question the server asks
shows as a question that takes one of its choices, never auto-answered.
A chat reopens its session with session/resume.
* fix(acp): separate Antigravity chat command and require pinned host
* test(acp): assert Antigravity launch arguments across hosts
* feat(acp): Antigravity chats offer Ask, Accept edits and Full access per chat
Each mode maps to the server's own (default, auto_edit, yolo). No Approve for me:
the server has no automatic reviewer. Accept edits gets its own description,
since auto_edit approves file edit tools only.
* feat(native-chat): offer host-provided chats without their CLI detected
A host now marks each agentSession.agents row whose chat program Orca provides there
(an ACP managed runtime with a pinned build on this host). With Chat UI on, the tab-bar
picker, the empty-workspace default chat and the new-agent shortcut offer those agents
beside the detected ones when the launch opens as a chat. Terminal launches still follow
detection, and an older host that sends no mark keeps today's detection-only offer.
* Fix CLI-free chat fallback and picker updates
* Fix admission refusal reason test expectation
* feat(native-chat): the host health snapshot says whether each chat's program is on the machine
Antigravity's chat runs Orca's own download of Google's ACP program, not the agy CLI, so clients
could not tell from CLI detection whether it can open as a chat. Each snapshot row now carries an
optional chatProgram (available, installable, missing, unknown), found through the agent's own
launch resolver without spawning anything, and re-derived after a managed runtime install or
removal. Health state and reason are unchanged, so older clients decode the frame as before.
* feat(native-chat): one renderer reading of whether an agent can open as a chat on its host
Pickers asked CLI detection whether an agent can open as a chat, which is wrong for Antigravity,
whose chat runs a program Orca downloads. This module answers from the host's published chat
program fact, and for hosts that publish none, from the host's managed-runtime mark and install
capability or else CLI detection. Facts not yet learned read as unlearned, not as no.
* fix(native-chat): a declined chat opens its agent's terminal only where the CLI is installed
Once a chat can be offered without its CLI, a host refusal used to fall back to a terminal that
runs a CLI that is not there. The one admission boundary now reports the host's refusal instead
when the workspace host's detected agents lack the CLI, for new-tab, work-item and workspace
creation launches alike. A caller's own fallback, like the empty workspace's shell, still opens.
* feat(native-chat): the + menu and Settings offer a chat wherever its program runs
With Chat UI on and no agy CLI, Antigravity had no chat row in the + menu (or a disabled
'Not installed' one when switched on), because both read CLI detection. The menu now reads the
host's chat-program answer: a chat row where the program runs or installs from the chat, no
'(CLI)' row or terminal button without the CLI. A failed CLI check no longer keeps the menu from
learning that answer. Settings shows an unchosen provider on when its CLI or the program Orca
runs for it (downloaded or found outside Orca) is installed, and holds the switch until that is
known. A saved default that opens as a chat no longer says it is not detected.
* feat(native-chat): a default agent that opens as a chat starts without its CLI
An empty workspace and the new-agent shortcut skipped a default agent whose CLI is not detected,
even when it opens as a chat on that host (Antigravity without agy). Both now honor that default,
waiting briefly for the host's chat facts when they are not known yet, while the automatic pick
with no default still chooses only detected agents. Blank and the shell fallback are unchanged.
* feat(native-chat): new workspaces, work items, continuations and the dashboard offer chat-only agents
The new-workspace composer, work-item launches, session continuation and the dashboard launcher
listed only agents whose CLI is detected, so an agent that opens as a chat without its CLI could
not be picked, and an explicit pick of it was dropped. They now also offer agents that open as a
chat on the workspace's host, keep such an explicit choice, and the dashboard republishes when
the host's chat facts arrive. Automatic picks still choose only detected agents.
* feat(native-chat): Source Control and Fix Checks accept a chosen agent that opens as a chat
The Source Control action dialog, its saved auto-start, the checks panel, recovery launches and
Fix Checks (before and after its workspace exists) rejected a saved or default agent whose CLI
is not detected, even where it opens as a chat. They now accept it there and list it, through
the shared source-control pick, while the automatic pick still chooses only detected agents.
* fix(native-chat): an empty workspace does not wait on chat facts for a Claude or Codex default
Claude and Codex have no program Orca downloads, so without their CLI only the host's own answer
could offer them as a chat; holding the workspace empty for the host's agent list could not
change that.
* test(native-chat): pin the chat-program fact, cold explicit defaults and the CLI-less decline
Covers the host's program lookup and its re-read after an install, older and unknown snapshot
values falling back to the managed mark and install capability of the same host, an explicit
default opening as a chat with CLI detection failed while automatic and blank picks stay on
detected agents, kept composer and saved Source Control choices, and a declined chat reporting
the refusal instead of opening a terminal for a missing CLI on both launch paths.
* refactor(source-control): the action dialog's agent list lives in its own hook
The dialog hook was over the file-length limit after it learned which agents
open as a chat without their CLI; detection and that offer now live together
in use-source-control-launchable-agents.
* fix: typed test mocks and record the dialog's pre-existing reset effect
The Source Control dialog's open-cycle reset effect was already on main; the
changed-code gate reported it because the effect now also learns which agents
open as a chat.
* fix(native-chat): a declined chat refuses its terminal only when the CLI is known to be missing
When a host declines a chat, Orca falls back to that agent's terminal. A chat can now be offered
without its CLI, so the fallback must not open a terminal that cannot start. But a failed or
still-pending CLI check is not proof the CLI is missing: treating it that way blocked a working
terminal fallback (for example an OpenCode version that runs in a terminal but not as a chat).
Each detection producer (local, paired server, SSH) now records the outcome of its latest attempt
for the exact target, next to the IDs it already keeps. The decline check refuses the terminal
only when the same host's latest attempt succeeded and did not list the CLI; pending, failed or
unresolved outcomes keep the existing fallback, and a caller's own shell fallback is untouched.
* fix(native-chat): every launch surface learns whether a chat opens before it decides
A chat whose program runs on the host without its CLI (for example Antigravity) could be missing,
greyed out or swapped for another agent depending on which surface launched it: the composer
dropped an explicit pick while the host was still answering, Fix Checks and the Checks panel
refused a saved chat agent, an inactive paired host was never asked about its chats, the Providers
switch flashed off, and session continuation auto-picked an agent that was only offered.
One lease per host, runtime and pairing now acquires the host's agent list and health stream
for whoever needs it: the + menu, composers, Settings, the dashboard and its pop-out, Source
Control and Checks, Fix Checks, work items, shortcuts and continuation. Actions wait for those
facts within one bounded deadline (ordinary CLI detection keeps its own wait), cancel when the
workspace's host is genuinely replaced, and re-read settings before launching. A saved, default
or explicit choice may open as a chat without its CLI; automatic picks still come only from
detected agents. Pending or unknown facts never erase a choice or flash a switch off.
The dashboard's holds are reconciled by the publishers that read them, and a hold that notifies
while it is being created no longer leaks a second stream holder.
* fix: the new-workspace composer memoizes its launch workspace from its own fields
* fix: a declined chat reads the launch host's own agent inventory; test fixtures match their types
* fix: work-item launches detect before waiting on chat facts; the composer and Source Control list agents from one owner
The composer card no longer holds its own chat-facts lease beside its modal's, Source Control reads agent
inventory only while its dialog is open, and a work-item launch keeps the new workspace's own detection
when the store has not loaded that workspace yet.
* fix(native-chat): keep acquisition tied to the current host resource
* fix(native-chat): verify the current acquisition before returning choices
* fix(i18n): retain legacy terminal-list English entries in the runtime catalog
* fix(native-chat): the dashboard republishes launch options when the active workspace's host changes
Both dashboard publishers now watch the active workspace and its selected host, which own its launch
options. Two QuickLaunchButton tests assert the current "couldn't list terminal agents" wording.
Restores base forms and drops a duplicate workspace helper to stay inside the change budget.
* test: the dashboard publisher test reads its watched state from the function it tests
* fix(native-chat): dashboards watch one checked route-input view; saved Source Control discovery settles every outcome
Both dashboard publishers observe and derive launch options from one exhaustive, compiler-checked view of
the store slices the launch-route readers take, so a route input can no longer be missed by one list. A
saved Source Control action's discovery now ends as success, cancelled or failed; only success can auto-start,
and a cancelled or failed attempt reveals the editable dialog instead of launching on a replacement runtime.
Restores base forms and shares one worktree workspace helper to stay inside the change budget.
* style: format the runtime metadata resolver
* fix: merge duplicate imports the code-quality gate rejects
* test: the dashboard watch fixture seeds every route-input field
* test: the dashboard watch fixture is fully typed without a cast
* fix: an unknown agent scan stays unknown for Fix Checks and recovery, and a saved Checks agent keeps its message
* fix: the action-first chat path asks the same missing-CLI check before opening a declined terminal; compact to the size cap
* refactor: compact the chat-program changes to the size cap after merging main
* Pickers list an agent that can't open here as disabled with its reason instead of hiding it
The Create workspace and continuation pickers only searched the agents the caller could launch, so an enabled agent with no chat on this host (for example Antigravity when the host can't run it) lost its disabled row, while the + menu showed it.
* Continuation test accepts more than one disabled subfolder row now that disabled rows are listed
* Re-run CI: the code scan was cancelled across the repository
* test: cover chat selection without terminal CLI
* test: compact host chat program fixtures
* ci: move routine checks and unsigned builds to Blacksmith
* ci: retain GitHub Mac images for isolated SSH fixtures
* ci: keep shared terminal perf preparation on Blacksmith
* test: allow encrypted slow-link fixture to finish on ARM CI
---------
Co-authored-by: OrcaWin <293788423+OrcaWin@users.noreply.github.com>
* ci: run relay integration on the Blacksmith x86 pool
* ci: use the validated Blacksmith pool for Linux packaging
* test: allow shared Linux download caches across validated runner pools
* perf(watch): stop watching all of userData and .git for a handful of files
On macOS a directory fs.watch is a recursive FSEvents stream. Two watches used
that to notice a few files:
- The Active Server preference watched the whole userData directory for
orca-environments.json, so Orca's own writes there (agent-hooks status,
terminal history, browser caches; ~10 events/s measured) were routed back
to it.
- The shallow git metadata watch ran fs.watch on each repo's whole common
.git dir (and .git/logs), receiving objects/, refs/, lfs/ and every linked
worktree's churn to see six files.
Both now watch the individual files (kqueue on macOS, no fseventsd) through a
new rebinding file watch: events and a 30s sweep re-stat the path, rebind when
a rename-replace or deletion moved it, and pick up files created later. Events
are confirmed by a stat (size/mtime/ctime/inode) because macOS raises an
attribute event for every mmap read of the index and packed-refs; the watch is
one-shot with a backing-off window so a file every git process maps costs about
one rebind a second instead of a wakeup per read. The registry path is
unchanged, so CLI/serve readers and older peers are unaffected. Linux and
Windows keep the non-recursive directory watch for shallow subscriptions.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(watch): don't hang unsubscribing an errored watcher; find late metadata files sooner
- Node closes an errored fs.watch handle without emitting 'close', and a later
close() is a no-op, so awaiting 'close' could hang a watcher-child unsubscribe
and every subscribe queued behind it. Errored watchers are now dropped without
a close, and closeFileSystemWatcher also settles on 'error' or after 1s.
Applies to both the macOS file watch and the Linux/Windows directory watch.
- Missing metadata files (packed-refs from pack-refs/gc) are re-statted every
2s instead of waiting for the 30s rebind sweep.
- On macOS the delivery probe watches a file, matching the kqueue path the
shallow subscriptions now use.
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
NeilandBingxin Xu
OrcaWinandOrcaWin
zhangxaochenandNeil
Brennan Benson
Kelvin Amoaba
Leo(오영택)andJaeyoung22
