Switching an agent to a different tenant: misleading 403 / reattach errors and no built-in re-target command

[dimitri-cybermatik]

Type: Feature Request

Summary

When an agent folder's .mcs/conn.json points to a tenant/environment the signed-in
account no longer has access to (a very common case: moving a project from an internal
tenant to a client tenant), the extension surfaces errors that point the user in the
wrong direction, and there is no supported way to re-target the connection. The actual
fix requires manually swapping .mcs/ metadata — which the docs explicitly tell users
not to touch.

Environment

• Copilot Studio VS Code extension:
• VS Code:
• OS: Windows 11

Repro steps

1. Have a local agent folder previously cloned/attached to Tenant A (so
   .mcs/conn.json references Tenant A's TenantId / EnvironmentId / AgentId).
2. The same agent now lives in Tenant B (e.g. project handed over to a client),
   and the signed-in account only has access to Tenant B.
3. Open the workspace / refresh the agent, or try Reattach.

Actual behavior

• Workspace refresh fails with:

Summary

When an agent folder's .mcs/conn.json points to a tenant/environment the signed-in
account no longer has access to (a very common case: moving a project from an internal
tenant to a client tenant), the extension surfaces errors that point the user in the
wrong direction, and there is no supported way to re-target the connection. The actual
fix requires manually swapping .mcs/ metadata — which the docs explicitly tell users
not to touch.

Environment

• Copilot Studio VS Code extension:
• VS Code:
• OS: Windows 11

Repro steps

1. Have a local agent folder previously cloned/attached to Tenant A (so
   .mcs/conn.json references Tenant A's TenantId / EnvironmentId / AgentId).
2. The same agent now lives in Tenant B (e.g. project handed over to a client),
   and the signed-in account only has access to Tenant B.
3. Open the workspace / refresh the agent, or try Reattach.

Actual behavior

• Workspace refresh fails with:
  Failed to refresh workspace .../EasyVista/: Error: Failed to fetch bot schema
  for Bot ID , status code: 403

• The Preview/sync panel shows:
  Dataverse request failed (403): {"error":{"code":"0x80072560",
  "message":"The user is not a member of the organization."}}

• Reattach fails with:
  Error reattaching agent: Agent directory is not valid for reattach.
  Try opening root of the selected agent folder

even though the selected folder is the agent root (contains agent.mcs.yml).

Expected behavior

• The 403 should be surfaced with its real cause, e.g.
  "The signed-in account does not belong to the tenant this agent is bound to
  (Tenant ). Sign in with an account from that tenant, or re-target the agent
  to a different tenant/environment."
• Reattach should either support re-targeting to a different tenant/environment,
  or fail with a message about the connection (not the directory structure), since the
  folder layout is valid.

Three issues here

1. Misleading 403 message. "Failed to fetch bot schema, 403" reads like an expired
   token, so users re-authenticate in a loop. The root cause (wrong tenant in
   .mcs/conn.json) is never communicated.
2. Misleading Reattach error. "Agent directory is not valid" makes users debug their
   folder structure, when the real problem is the bound connection.
3. No supported re-target path. There is no command to point an existing agent folder
   at a different tenant/environment. The only working workaround is to clone the target
   agent into a temp folder and manually copy its .mcs/ (conn.json, botdefinition.json,
   changetoken.txt) over the original — directly contradicting the guidance that .mcs/
   is tool-managed and must not be hand-edited.

Secondary annoyance: "phantom workspaces"

Any backup folder that contains an agent.mcs.yml (e.g. a safety copy made before the
swap) is picked up as a separate agent workspace. These extra entries then emit their
own confusing errors (conn.json is missing, please clone again, or the Tenant A 403),
making it look like the real fix didn't work. Consider scoping agent discovery (e.g.
ignore dot-folders / *.bak / clearly-marked backup folders), or letting users dismiss
a workspace from the panel.

Suggested fix

• A first-class "Re-target / Change tenant" command that re-points an existing agent
  folder to a chosen tenant + environment (reusing the same flow as clone, but writing
  .mcs/ in place).
• Clearer 403 and Reattach error messages that name the bound tenant and the likely cause

Extension version: 1.4.37
VS Code version: Code 1.123.2 (3c631b164c239e7aeaaae7c626b46c527b361af2, 2026-06-09T15:06:40-07:00)
OS version: Windows_NT x64 10.0.26200
Modes:

System Info

Item	Value
CPUs	AMD Ryzen 9 7940HS w/ Radeon 780M Graphics (16 x 3992)
GPU Status	2d_canvas: enabled GPU0: VENDOR= 0x10de, DEVICE=0x28a0 [NVIDIA GeForce RTX 4060 Laptop GPU], DRIVER_VENDOR=NVIDIA, DRIVER_VERSION=32.0.15.9636 ACTIVE GPU1: VENDOR= 0x1002, DEVICE=0x15bf [AMD Radeon(TM) 780M], DRIVER_VERSION=31.0.24027.1012 GPU2: VENDOR= 0x1414, DEVICE=0x008c [Microsoft Basic Render Driver], DRIVER_VERSION=10.0.26100.8521 Machine model name: Machine model version: direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off trees_in_viz: disabled_off video_decode: enabled video_encode: enabled webgl: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	31.22GB (11.09GB free)
Process Argv	--crash-reporter-id 6c305a60-fa32-4bd0-b4d1-a3ae0427f23b
Screen Reader	no
VM	0%

A/B Experiments

vsliv368cf:30146710
vswsl492:30256859
binariesv615:30325510
nativeloc1:31344060
dwcopilot:31170013
dwoutputs:31242946
copilot_t_ci:31333650
e5gg6876:31282496
pythonrdcb7:31342333
6518g693:31463988
aj953862:31281341
4f60g487:31327383
6abeh943:31336334
envsdeactivate2:31505458
cloudbuttont:31379625
3efgi100_wstrepl:31403338
ec5jj548:31422691
cp_cls_t_966_ss:31526232
4je02754:31466945
8hhj4413:31478653
ge8j1254_inline_auto_hint_haiku:31490510
38bie571_auto:31478677
cp_cls_c_1081:31454833
conptydll_true:31498968
ia-use-proxy-models-svc:31452481
e9c30283:31461165
test_treatment2:31471001
c9b86496:31447327
rl_b_xe_098a3278:31529126
idci7584:31464702
e3e4d672:31494082
ei9d7968:31496641
nes-extended-on:31455476
chat:31457767
8hig5102:31480529
89g7j272:31518289
7e187181:31503455
i2gc6536:31499202
52612955:31516516
ghj88844:31499326
23c7c724:31520045
ddid_t:31478206
hmra_i5g22:31518061
7df3h592:31512476
pro_large_t:31499376
cp_cls_t_1082:31516087
logging_enabled_new:31498466
db5d2638:31499441
jb_cp_cls_c_632:31524806
b1ei0813:31506238
56dj4588:31512888
32d76977:31512328
ha629193:31508444
cdk-lw-on:31524445
nes-charagree-3:31521372
31fi7170_t:31522396
hgf2d445:31529595
prpt_srch:31518468
95db8703:31523165
61138546:31518536
d7b18187:31526828

[nguhoa]

to reattach, please remove .mcs and reopen vscode to load project again (make sure it is root folder of agent. if you have agents/agent1/.mcs, then open folder agent1). We will look into support for reattaching with existing of .mcs but for now, we only support reattach when it has no .mcs. when you remove .mcs, there is no error check for account of that project anymore and then you can reattach to new tenant/environment that you want.

[dimitri-cybermatik]

Thanks for the workaround — deleting .mcs/ and reattaching does work, so the immediate blocker is resolved. That said, the core of this issue is a feature request, not a support question: the three points (misleading errors, no re-target command, phantom workspaces) still stand. Could the label be changed back to reflect that?

[nguhoa]

Thanks for the request. We are working on it and will let you know when we release it. Thanks

[nguhoa]

Can you please share why you want this feature to retarget new environment/tenant. And what is your scenario for this reattachment? Can you describe more detail like what type of agent you are working and how you expect reattachment work?