Why make another web-based repl for arc when there is already palsecam's evsrv , nostrademons' ArcLite , thaddeus' wterm project  and pg's prompt.arc? (Are there others?)
These projects don't serve identical purposes. Try Arc is meant to be a tool for introducing people to Arc in a hands-on way. Sandboxed eval makes this safe and Chris Done's jquery-console makes it convenient (that is, once I've worked some of the kinks out). It is probably suboptimal for real development though (beyond as some sort of scratchpad) since it doesn't offer persistence: accidentally refresh the page and you lose your work.
prompt.arc, on the other hand, is nice for real development. Not only can you try things out at the repl, but you can plug them in as real applications at the prompt. However, it wouldn't be as good in the Try Arc context since it calls raw eval, granting access to the underlying system (it's a double-edged sword).
evsrv is great. Sandboxed eval plus persistence for multiple users, and you can even start an anonymous session, all at an ajaxified terminal? palsecam mentioned in  that he used mzscheme for sandboxing as well; there may be some useful ideas in what he's done for this project.
The sandbox library seems to work fairly well. Using the awesome quasiquote bug/feature that lets you drop to Scheme, I was able to evaluate (current-directory) --> "/root/arc/arc3.1/" and (version) --> "4.1.5", but the functions 'directory-list (like "ls"), 'open-output-file, and 'system don't do anything. Also, (current-directory <something>), which would change the current directory, doesn't do anything. That's probably somewhat reassuring to know, security-wise. (Someone has to try these things out, and it may as well be me, who intends to do no harm, before it's someone else, who might feel mischievous.)
By the way, an end-user can emulate stdout by doing something like this:
@waterhouse thank you for your eval-w/stdout function. I tried about twelve variations on the idea but ended up back at exactly the definition you gave. Even one cosmetic change that I was sure would be an improvement turned out to make it harder to read (at least in my opinion):
2. strings.arc, pprint.arc and html.arc are now all included in the sandbox:
arc> (plural 2 "dog")
; not indenting properly
arc> (ppr:macex1 '(accum a (each x '(1 2 3) (a x))))
(withs (gs954 nil
(fn (_) (push _ gs954)))
(each x (quote (1 2 3)) (a x))
arc> (tag strong (link "Arc Forum" "http://arclanguage.org"))
<strong><a href="http://arclanguage.org">Arc Forum</a></strong>"</strong>"
At least for the moment I'm not including srv.arc, app.arc, code.arc and prompt.arc. Most of their functions couldn't be used in the sandbox anyway, and I can conserve resources (i.e. loading them in for each new user) by leaving them out.
Using the awesome quasiquote bug/feature that lets you drop to Scheme...
That is an awesome bug/feature.
To be sure, what you get at that repl isn't pure arc3.1 (at least for now it's not). It's arc3.1 plus anarki's $ minus libs.arc. So since it has $, you can drop to scheme without even exploiting rocketnia's discovery. You just can't do much harm there (at least, you're not supposed to be able to do much harm there, and you just helped me gain a bit of confidence about that).
It does concern me that you're able to see the current directory and version, but I guess as long as you're not able to change anything on the system it might be ok.
(Someone has to try these things out, and it may as well be me, who intends to do no harm, before it's someone else, who might feel mischievous.)
I completely agree. Thank you for trying to break it and reporting your results.
Suggestion: The Arc toplevel binds the variables "that" and "thatexpr" every time you enter something: the expression typed in becomes thatexpr and the value of the expression becomes that. I think it would be really nice, and also easy, to add that feature.